on rtnF

I'm a language engineer by trade. Naturally, this leads a person to sketch their own hobby projects. I've been doing so for a long time and finally decided to show one such prototype to my manager at the time. Mozilla took an interest and set up a team to work on this language as a component of longer-term project to rebuild their browser stack around safer, more concurrent, easier technologies than C++. That larger project is called "servo". Mozilla is funding Rust development because of that.

Why yet another new language? Because, a lot of obvious good ideas, known and loved in other languages haven't made it into widely-used systems languages, or are deployed in languages that have very poor (unsafe, concurrency-hostile) memory models. There were a lot of good competitors in the late 70s and early 80s in that space, and I wanted to revive some of their ideas and give them another go, starting with the basic premise that : "the internet is highly concurrent and highly security-conscious, so the design-tradeoffs that always favor C and C++ have been shifting."

Our target audience is "frustrated C++ developers". So if you are in a similar situation we're in, repeatedly finding yourself forced to pick C++ for systems-level work due to its performance, but would like something safer and less painful, we hope we can provide that.


Hi! I have been writing a compiled, concurrent, safe, systems programming language for the past four and a half years. Spare-time kinda thing.

Why? Because there are problems with C++ . Memory unsafe, no ownership policies, no concurrency control, it can't even keep const values constant. It also heavily burdened with legacy issues, with weird compilation model, weak linkage and module system, and nigh-impossible to write tools for.

Now we're introducing "Rust". Rust is a language that mostly cribs from past language. Definitely nothing new here. We're concentrating on known ways of achieving safety, concurrency, with less mess. Rust is inspired by 80s / 90s languages : Ni (1981), Hermes (1990), Erlang (1987), Sather (1990), Newsqueak (1988), Alef (1995), Limbo (1996) and Napler (1985).

Current implementation status : 38kloc bootstrap compiler (ocaml), built-in x86 backend for Linux, Wind32 and OSX. LLVM backend is still in progress. Currently we need some help from experienced language implementors, or anyone who feels like bug-fixing or library-writing. But please, no novelty (there's plenty of known-good technology in the literature) . Also please, skip bikeshed arguments.


I burnt out, ran out of emotional energy to be effective in my role as technical lead for the project midway through 2013. So I took a break, switched off the Rust team, took a year to work on lower-profile projects inside Mozilla (test-farm automation for Firefox on Android, wifi and cell geolocation service), eventually quit Mozilla, worked for a completely unrelated payment network (Stellar) doing a distributed transaction processor. Finally, in early 2016 I got a call from someone at Apple saying they were looking for some folks to help with Swift, in a non-leadership position, something which I prefer.


I'm extremely pleased to see the rust project reach its first major turning-point release, 1.0-alpha.

Out of curiosity, I ran a query against the current source repo. There are 343,510 lines in it. I am the 3rd highest non-robot committer in the history. Excluding adventures in bulk-relicensing, there are currently a mere 5,293 lines there that I wrote. Of that, 3,126 is docs, configure and build infrastructure. There are 2,167 lines of Actually Meaningful Code from me in here, which is mostly statistical test vectors and POSIX typedefs.

It's a somewhat strange feeling, but "success" in a big software project generally looks like "enough other people got involved that my own contributions vanish in the activiy". Rust has grown to be a remarkably collective project : 559 contributors! Congratulations, everyone!


Someone argues that Rust's marketing pitch focuses too much on safety, and that topic doesn't really resonate with everyone.

There is part of me that winces when someone goes looking for a justification for Rust above and beyond safety. Safety in the system space is Rust's raison d'etre, especially safe concurrency, or even, fearless concurrency.

When someone says they dont have safety problems in C++, I am astonished. Quite a statement that must made in ignorance, if not outright negligence. The fact of the matter is that the further down the software stack one goes, the worse the safety situation gets. Every day, the world stumbles forward on creaky, malfunctioning, vulnerable, error-prone systems software and every day the toll in human misery increases. Billions of dollars, countless lives lost. Can one really say "I don't have safety problems" in systems programming? Show me a language with manual memory management and threading and I will show you an engineering tragedy waiting to happen.

That's what Rust has always been about : bringing safety features to the systems niche, a niche that has stubbornly resisted them for decades while higher-level languages have moved ahead in safety.


Hello! I am someone who has worked (for pay!) on some compilers : rustc, swiftc, gcc, clang, llvm, tracemonkey, etc. Ron asked if I could talk about compiler stuff I know, giving some perspective on the field a bit. My goal for this talk is to reduce terror, spark curiosity, and encourage trying it as career! If I can compiler, so can you!

The first compiler :

Compiler considerations :

Several compiler speciments :


  1. Abel Avram (August 3, 2012) "Interview on Rust, a Systems Programming Language Developed by Mozilla" InfoQ
  2. Graydon Hoare (January 16, 2018) "I wonder why Graydon Hoare stopped contributing into Rust and switched to Swift" /r/rust
  3. Graydon Hoare (July, 2010) "Project Servo : Technology from the past come to save the future from itself" Mozilla Annual Summit
  4. Graydon Hoare (January 12, 2015) "Rust"
  5. Graydon Hoare (2019) "21 Compilers and 3 Orders of Magnitude in 60 Minutes"

P.S : No, i'm actually not a language engineer by trade. As you may realize, i just summarized Hoare's posts here and there, while keeping his first-person point of view in this article.