The unsung hero of Rust

By Brian Handong

Original text: brson. Dead simple. IO / 2021/05/02 /…

Brian Anderson was previously a senior Research engineer at Mozilla Research and a member of the Rust core team. Worked on the Rust programming language for 6 years, maintaining runtime and standard libraries, building infrastructure for validation languages and their subsystems. One of the main authors of Servo’s browser. Rust is known for its stability, and Brian’s mission is to make Rust the most reliable platform. He joined PingCAP in 2018.

I think Rust is a great success at the moment. When I think back on how it all happened, I am in awe. Because you had to do so many things right to get where you are, and there were so many opportunities to make mistakes along the way. By one small miracle after another, the Rust language became what it was supposed to be. These miracles do not happen by chance, but by real people. These real people, through careful planning, are already great.

There are many people who have contributed to Rust’s growth. Some of those responsible for Rust’s success are barely known.

Start: Mozilla Institute

By 2009, Mozilla had amassed a substantial cash pile from its search deal with Google. As I understand it, management decided it was time to invest the money and the company entered a period of rapid expansion.

As part of the expansion, Mozilla created a new division, Mozilla Research. The division’s mission is to try out ambitious ideas independently of the Firefox product, while building ties with the computer science community.

The Mozilla Institute’s first major idea was Servo. And then Rust.

Dave Herman was one of the people appointed to lead the department at the time.

Who is Dave Herman?

Dave Hellman is a programming language theorist, a macrologist, and one of Mozilla’s representatives on the ECMAScript Committee.

He and Graydon Hoare, the engineer who created Rust, had worked together on the now-abandoned ECMAScript 4 standard.

They both have a passion for creating programming languages.

There’s a lot of work going on at the Mozilla Institute besides Servo, Rust and Dave Hellman, but that’s outside of our story.

We tell the story of how Dave Herman quietly shaped the results of Project Rust.

Dave’s contribution to Rust

Rust was released in June 2010, but it has actually been under development within Mozilla since late 2009. The only public record of this Rust development past is in the Graydon/Rust-PreHistory repository.

Rust went through a six-month sprint from its inception to its presentation to the public in June 2010. And Dave was one of the people who tackled that task.

~/rust-prehistory $ git shortlog -sn
  1156  Graydon Hoare
   163  Andreas Gal
   104  Dave Herman
    59  [email protected]
    55  Patrick Walton
    37  Graydon Hoare ext:(%22)
    13  Roy Frostig
     9  [email protected]
     6  Brendan Eich
     5  Michael Bebenita
     1  Brian Campbell
Copy the code

He has since turned over coding to the growing Rust team led by Graydon. But for the next few years, Dave was always in the office.

At the time, most of the people who worked for Rust were in the same office. Rust’s other key figure, Graydon, is remote. Dave and a handful of full-time employees, along with rotating interns, regularly gather around a table in a small conference room at Mozilla’s Mountain View headquarters.

I can imagine him acting as a mentor, relying on his experience with ECMAScript and his interest in language design to push the team in productive directions. He has never exercised his authority in any way and, to this day, has not claimed any credit for himself on Rust.

He made his contribution almost entirely behind the scenes, quietly exerting his influence.

Many of the early arguments that took place in that room were foundational. These arguments seem irrelevant today, such as “What is the key returned from the function?” “Or” how to safely hold Pointers to struct fields.” These questions seem remote and irrelevant today, but because of such arguments Rust keeps shaping and reshaping until all the small problems have been resolved into a coherent whole.

Dave was one of the few people in the room with real production programming language design experience, and without him leading the team through trivial language design hurdles Rust would have been a mess. Dave’s tastes shaped the team’s tastes, and thus the Rust language. And, for the most part, Dave was happy with the team’s decisions.

Although Dave had a voice in all of the early Rust design themes, there are a few that captured his interest in the language, and if you know Rust at all, I suspect you’ll be familiar with them:

• Pedagogy. That is, teaching methods.

Dave has an academic background and always considers every decision about design in terms of how to teach and understand it.

• Governance. That is, community management.

Rust was designed as a community project from the beginning, and I think this was largely influenced by Dave’s experience working with language standards bodies. It has always been assumed that the most successful languages are designed not by anyone but by a large group of individuals and companies working together, all superimposed on their own interests and motivations. As a result, the process under which Rust develops is always as inclusive as possible at the time. To take one example, many of Rust’s earliest developments are recorded in public meeting minutes. I attribute this almost entirely to Dave’s self-discipline and the fact that many of these recordings were made by him personally. Dave’s most important Rust legacy may be the cultivation of a language community.

• Macro.

As mentioned, Dave is a macro expert. He is proficient in Macro and has a background in the Racket language. Although largely implemented by interns (specifically Paul Stansifer), with some key contributions from John Clements, Rust has powerful and hygienic declaration macro_rules! Thanks to Dave. . Although this is not my area, I remember him and Paul spending a lot of time talking about how to design a traditional Lisp-style sanitary macro system for the C-like world of Rust.

Other key decisions Dave was involved in included:

• Convert the Rust language from a statement language to an expression language.
• Niko was hired to design the Rust ownership system.
• Yehuda Katz was hired to design Cargo.

In addition to these obvious contributions, Dave plays another key role in Rust: championing it in management.

Of all the wonders of Rust, perhaps the greatest are Mozilla’s many efforts. Throughout the time Rust was in Mozilla, there was a palpable sense within the team that the project could be cancelled at any moment. This is especially true after The departure of Brendan Eich, a stickler for the Rust team, from Mozilla. This is one of the reasons why it is important to build a strong community around the language.

Dave is the most senior Rust believer in the company. Moreover, he did everything he could to promote Rust’s importance to the company’s mission and to accommodate Rust’s staffing and resources. True, I had no idea what Dave was up against in his management role, but this was absolutely key: he managed to keep the team focused on Rust.

In any case, Rust was always understaffed. I remember being angry about it: how can we compete with Google and Apple with so few full-time engineers? Surely half the answer is to cultivate a diverse community of contributors, but this is a slow and uncertain process. The other half of the answer to that question is Dave: the intern. Rust usually has more interns than full-time employees, and they are all hired by Dave, who can easily recruit PL talent with his academic integrity.

One laudable fact: Rust was primarily created by students, many of whom interning at Mozilla.

Anecdotes about Rust’s design

I thought I’d offer a few anecdotes about Dave’s contributions to Rust design, and the first that comes to mind is that he disagreed with the team’s decisions. This is not a great example of Dave’s contribution, but it may still be worth sharing, and is an example of how he guides the team while also trusting their decisions.

It’s still hard to remember the exact details, but the scene I remember most was when Dave strongly disagreed with the team’s decision to introduce a distinction between mutable and immutable variable bindings. We’re just deciding what syntax to use for each syntax, which is easy. At the end of the debate, there are two obvious choices for immutable and mutable bindings:

• let 和 let mut
• let 和 var

The first is the syntax we’ve adopted so far, the second is borrowed directly from JavaScript, and there are good reasons for both. The main question then was whether to choose a more appropriate grammar from “harder” or “uglier”. Language designers force programmers to type two keywords to create variable bindings, subtly influencing programmers to think more about introducing variability.

I remember Dave disagreeing with the team’s decision in that regard. In retrospect, I don’t think he agreed with the principle of “severely limiting the user’s choice of encoding modes,” but I’m not sure. I also still think the team is right about this: not only do additional MUT annotations add some extra work to increase variable variability, but MUT annotations naturally extend to other areas of Rust type systems, such as & MUT references. Moreover, the identification and management of variability has become an essential feature of the language.

Lay the foundation for success

My guess is that Dave’s direct involvement in Rust’s design ended in 2014 or 2015, and most people in the Rust community weren’t even aware of his existence.

Dave didn’t invent Rust.

He contributed only six commits to the public Rust repository. He only spoke on the mailing list four times.

What he has done is to create a team that he believes can bring a unique vision to the world, and to subtly implant within that team a set of values that will enable Rust to transcend Mozilla’s boundaries and the involvement and individuality of any single individual.

That’s exactly what happened.

There are many reasons for Rust’s success, among which there are thousands of contributors, thousands of tiny miracles converging into a coherent whole.

But small miracles don’t become big ones by accident.