I’ve been a programmer since the age of 8, and some kind of developer for most of my life. Throughout my life as a coder, both hobbyist and professional, I’ve learnt plenty of programming languages that felt like cookie-cutter clones of each other, but also a few programming languages that changed the way I looked at programming, sometimes even at thinking.

(This is meant to be the first entry of a series which will cover individual points more in depth. We’ll see how that goes.) We’re the tech industry. We have ideas. We have ideas all the time. And we’re used to turn our ideas into applications. So, how does it go… here’s the back-end component… here’s the front-end component. We’ll write the former in Python, or perhaps JavaScript, to optimize for prototyping. After all, we have so many ideas, we need the ability to iterate quickly. Sprinkle in a few dependencies, that will speed us up. Oh, and let’s use ChatGPT and Copilot, we’ll be even faster. Oh, and performance, yeah, performance: microservices, Kafka, Redis, Kubernetes… we’re now ready to scale up. Oh, Sentry, Prometheus and Grafana, too, where would we be without ’em? For the front-end, we’ll write a website, and for mobile, Electron. Oh, wait a second, we need to make money and to fidelize our users! Let me see… ads, tracking, and good reasons to revisit our app, perhaps a little NFT here, gamification… alright, we should be good. Three… two… one… and we have shipped v1! Also, the world is burning. Perhaps it’s time we revisited how we do things?

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.

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.

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 :)

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.

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.

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.