Mozilla on Il y a du thé renversé au bord de la table, by David "Yoric" Teller

(Quite) A Few Words About Async

Tue, 08 Jul 2025 22:09:29 +0200

I’ve had a few conversations about async code recently (and not so recently) and seen some code that seems to make wrong assumptions about async, so I figured out it was time to have a serious chat about async, what it’s for, what it guarantees and what it doesn’t.

What would it take to add refinement types to Rust?

Sun, 22 Dec 2024 20:00:47 +0100

A few years ago, on a whim, I wrote YAIOUOM. YAOIOUM was a static analyzer for Rust that checked that the code was using units of measures correctly, e.g. a distance in meters is not a distance in centimeters, dividing meters by seconds gave you a value in m / s (aka m * s^-1).

YAIOUOM was an example of a refinement type system, i.e. a type system that does its work after another type system has already done its work. It was purely static, users could add new units in about one line of code, and it was actually surprisingly easy to write. It also couldn’t be written within the Rust type system, in part because I wanted legible error messages, and in part because Rust doesn’t offer a very good way to specify that (m / s) * s is actually the same type as m.

Sadly, it also worked only on a specific version of Rust Nightly, and the code broke down with every new version of Rust. It’s a shame, because I believe that there’s lots we could do with refinement types. Simple things such as units of measure, as above, but also, I suspect, we could achieve much better error messages for complex type-level programming, such as what Diesel is doing.

It got me to wonder how we could extend Rust in such a way that refinement types could be easily added to the language.

About Safety, Security and yes, C++ and Rust

Fri, 03 Feb 2023 21:54:25 +0100

Recent publications by Consumer Reports and the NSA have launched countless conversations in development circles about safety and its benefits.

In these conversations, I’ve seen many misunderstandings about what safety means in programming and how programming languages can implement, help or hinder safety. Let’s clarify a few things.

yoric.steps.next()

Mon, 26 Oct 2020 16:33:46 +0200

The web is getting darker. It is being weaponized by trolls, bullies and bad actors and, as we’ve witnessed, this can have extremely grave consequences for individuals, groups, sometimes entire countries. So far, most of the counter-measures proposed by either governments or private actors are even scarier.

The creators of the Matrix protocol have recently published the most promising plan I have seen. One that I believe stands a chance of making real headway in this fight, while respecting openness, decentralization, open-source and privacy.

I have been offered the opportunity to work on this plan. For this reason, after 9 years as an employee at Mozilla, I’ll be moving to Element, where I’ll try and contribute to making the web a better place. My last day at Mozilla will be October 30th.

about:Mozilla's blockers and needinfos

Thu, 08 Oct 2020 12:15:16 +0200

On this rainy october day (well, at least it rains where I’m writing this) of the great year 2020, let’s take another few minutes to reflect on some great practices that we have at Mozilla and that would deserve to take over the world.

Today, let’s talk about what you can do when your work is blocked.

about:Mozilla's #introduction channel - and how it could work for your project

Tue, 06 Oct 2020 11:06:16 +0200

Let’s continue this series on some of the great practices that we have at Mozilla and that your project may wish to adopt, too.

This time, let’s talk about Mozilla’s #introduction chatroom.

about:Mozilla's Mentored Bugs - and how it could work for your project

Fri, 02 Oct 2020 13:44:16 +0200

2020 is a crappy year for pretty much everyone. As you may have seen, this includes organizations such as Mozilla. So I figured it was the best time to actually talk about good stuff! This entry should be the first of a series of short articles dedicated to some great practices we have at Mozilla and that I think many open-source projects could adopt.

At its core, Mozilla is a community of open-source enthusiasts. When you’re new to an open-source community and you wish to start contributing somewhere, finding an entry point is often difficult.

This is where Mentored Bugs come in.

Why Did Mozilla Remove XUL Add-ons?

Thu, 20 Aug 2020 18:09:36 +0200

TL;DR: Firefox used to have a great extension mechanism based on the XUL and XPCOM. This mechanism served us well for a long time. However, it came at an ever-growing cost in terms of maintenance for both Firefox developers and add-on developers. On one side, this growing cost progressively killed any effort to make Firefox secure, fast or to try new things. On the other side, this growing cost progressively killed the community of add-on developers. Eventually, after spending years trying to protect this old add-on mechanism, Mozilla made the hard choice of removing this extension mechanism and replacing this with the less powerful but much more maintainable WebExtensions API. Thanks to this choice, Firefox developers can once again make the necessary changes to improve security, stability or speed.

During the past few days, I’ve been chatting with Firefox users, trying to separate fact from rumor regarding the consequences of the August 2020 Mozilla layoffs. One of the topics that came back a few times was the removal of XUL-based add-ons during the move to Firefox Quantum. I was very surprised to see that, years after it happened, some community members still felt hurt by this choice.

And then, as someone pointed out on reddit, I realized that we still haven’t taken the time to explain in-depth why we had no choice but to remove XUL-based add-ons.

So, if you’re ready for a dive into some of the internals of add-ons and Gecko, I’d like to take this opportunity to try and give you a bit more detail.

Possibly one step towards named arguments in Rust

Sat, 08 Aug 2020 08:46:22 +0200

A number of programming languages offer a feature called “Named Arguments” or “Labeled Arguments”, which makes some function calls much more readable and safer.

Let’s see how hard it would be to add these in Rust.

Units of Measure in Rust with Refinement Types

Fri, 17 Jan 2020 13:35:02 +0100

Years ago, Andrew Kennedy published a foundational paper about a type checker for units of measure, and later implemented it for F#. To this day, F# is the only mainstream programming language which provides first class support to make sure that you will not accidentally confuse meters and feet, euros and dollars, but that you can still convert between watts·hours and joules.

I decided to see whether this could be implemented in and for Rust. The answer is not only yes, but it was fun :)

Thinkerbell Postmortem/Brain dump

Thu, 08 Mar 2018 08:50:05 +0100

Two years ago, I was working on a research project called “Project Link” as part of the Connected Devices branch of Mozilla. While this branch has since been stopped, some part of Project Link lives on as Project Things.

One of the parts of Project Link that hasn’t made it to Project Things (so far) was Thinkerbell: a Domain-Specific Language designed to let users program their SmartHome without coding. While only parts of Thinkerbell were ever implemented, they were sufficient to write programs such as:

Whenever I press any button labelled “light” in the living room, toggle all the lights in the living room.

If the entry door is locked and the motion detector notices motion, send an alarm to my SmartPhone.

Thinkerbell also had:

semantics that ensured that scripts could continue/resume running unmonitored even when hardware was replaced/upgraded/moved around the house, including both the server and the sensors;
a visual syntax, rather than a text syntax;
a novel type system designed to avoid physical accidents;
a semantics based on process algebras.

Ideally, I’d like to take the time to write a research paper on Thinkerbell, but realistically, there is very little chance that I’ll find that time. So, rather than letting these ideas die in some corner of my brain, here is a post-mortem for Thinkerbell, in the hope that someone, somewhere, will pick some of the stuff and gives it a second life.

Note that some of the ideas exposed here were never actually implemented. Project Link was cancelled while Thinkerbell was still in its infancy.

HolyJIT: Could we write a multi-staged JIT compiler?

Tue, 06 Mar 2018 07:33:25 +0100

Credit

While I’m the author of this blog post, 99% of the work was done by Nicolas B. Pierron.

So far, my role in this project has largely been to play the wise old advisor, nodding and smiling mischeviously whenever Nicolas started exploring new ideas, and emitting cryptic comments in Reverse Jedi Notation.

A few months ago, we published a short (and mysterious) blog post in which we mentioned HolyJIT, an early research project towards a novel approach to writing JITs.

In this blog post, I would like to detail a bit more the ideas behind HolyJIT.

JavaScript Binary AST diaries - How to replace proving with validating for fun and profit

Fri, 23 Feb 2018 10:44:39 +0100

In this entry, I’d like to discuss one of the most interesting and unusual aspects of the Binary AST: how we gain performance by turning proof-building into validation, and why this is very good news for performance (and maybe not so good news for file size).

Typestates in Rust

Thu, 22 Feb 2018 15:15:55 +0100

A long time ago, the Rust language was a language with typestate. Officially, typestates were dropped long before Rust 1.0. In this entry, I’ll get you in on the worst kept secret of the Rust community: Rust still has typestates.

Binary AST - Motivations and Design Decisions - Part 1

Thu, 07 Sep 2017 23:31:43 +0200

“The key to making programs fast is to make them do practically nothing.” - Mike Haertel, creator of GNU Grep.

Binary AST - “Binary Abstract Syntax Tree” - is Mozilla’s proposal for specifying a binary-encoded syntax for JS with the intent of allowing browsers and other JS-executing environments to parse and load code as much as 80% faster than standard minified JS.

It has recently cleared Stage 1 of the TC39 standards process, and while the final byte-level format isn’t completely nailed down, we’re confident that the final implementation will deliver the impressive performance improvements promised by the prototype.

JavaScript Binary AST Engineering Newsletter #1

Fri, 18 Aug 2017 13:46:54 +0200

Hey, all cool kids have exciting Engineering Newsletters these days, so it’s high time the JavaScript Binary AST got one!

Summary

JavaScript Binary AST is a joint project between Mozilla and Facebook to rethink how JavaScript source code is stored/transmitted/parsed. We expect that this project will help visibly speed up the loading of large codebases of JS applications and will have a large impact on the JS development community, including both web developers, Node developers, add-on developers and ourselves.

Towards a JavaScript Binary AST

Thu, 03 Aug 2017 23:31:43 +0200

In this blog post, I would like to introduce the JavaScript Binary AST, an ongoing project that we hope will help make webpages load faster, along with a number of other benefits.

A little background

Over the years, JavaScript has grown from one of the slowest scripting languages available to a high-performance powerhouse, fast enough that it can run desktop, server, mobile and even embedded applications, whether through web browsers or other environments.

Project Lighthouse: A post-mortem

Mon, 20 Feb 2017 10:44:33 +0100

A few weeks ago, Mozilla pulled the plug on its Connected Devices Experiment: a bunch of internal non-profit hardware-related startups. One of our main objectives was to determine if we could come up with designs that could help turn the tide against the spyware-riddled and gruyère-level security devices that are currently being offered (or pushed) to unwary users.

One of the startups was Project Lighthouse. We tried to provide an affordable, simple and privacy-friendly tool for people suffering from vision impairment and who needed help in their daily life. While Mozilla closed the experiment before we could release anything useful, we still came up with a few nifty ideas. Here is a post-mortem, in the hope that, maybe, someone will be able to succeed where we couldn’t.

Things to do before you[r project] die[s]

Fri, 17 Feb 2017 00:10:34 +0100

It’s no secret that all projects die, eventually, and that most projects die before they have had a chance to have any impact. This is true of personal projects, of open-source projects, of startup projects, of hardware projects, and more.

A few days ago, the IoT project on which I was working did just that. It was funded, it was open-source, it was open-hardware, and it still died before having the opportunity to release anything useful. In our case, we got pretty far, didn’t run out of funds, and were a little polish away from putting our first alpha-testers in front of a pretty advanced prototype before a higher-level strategy pivot killed a number of projects at once.

Ah, well, risks of the trade.

Still, working on it, we managed to learn or come up with a few tricks to increase the chances of surviving at least long enough to release a product. I’ll try to summarize and explain some of these tricks here. Hopefully, if you have a project, regardless of funding and medium, you may find some of this summary useful.

Extracting text from images is not easy (who would have guessed?)

Sun, 01 Jan 2017 23:44:19 +0100

At its core, Lighthouse is an idea we have been discussing in Connected Devices: can we build a device that will help people with partial or total vision disabilities?

From there, we started a number of experiments. I figured out it was time to braindump some of them.

Our problem

Consider the following example:

How do we get from this beautiful picture of Mozilla’s Paris office to the text “PRIDE and PREJUDICE”, “Jane Austen”, “Great Books”, “Great Prices”, “$9.99”, “Super livres”, “Super prix”? That’s Canadian dollars, if you wonder.