This is a neat backstory, glad to see more “behind the scenes” rust development.
To me, the person I feel doesn’t get enough credit (though he does get a lot) is Niko Matsakis. As I understand the progression of rust, it started as a higher level, green threaded ML variant of sorts, and ended as this low level systems programming language we know today. But the key thing that defines rust, I think, is the borrow checker ownership model, which I think is thanks mostly to Niko. So while Graydon gets the credit for creating rust, I almost feel that was a different language, and the true “father” of rust as we know it is Niko.
And then I get wondering what it would have been like had the language been designed around the borrow checker from the start, or if that had been bolted onto a different language. I wonder if a “C with borrowck” is possible and what that looks like. I personally love rust’s ML heritage and traits and iterators and RAII but I think it maybe turns off some hardcore low level and embedded developers, and they more than anyone are who we need to give memory safety to.
Borrow checker is one candidate, but that’s an implementation. I think the key thing that defines Rust is its value. Rust’s value is Graydon’s contribution. Yes, Rust had an extremely different implementation, but it always had the same value. At least from the first public release to 1.0.
The current website says “Rust is a language empowering everyone to build reliable and efficient software”, but that’s post-1.0 change. (I actually consider this the most significant post-1.0 change. I think it was almost a coup.)
The previous website says “Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety”. That’s it. That’s Graydon’s contribution. It implies, Rust is not a simple language. Rust is not a language that is easy to learn. Rust is not a language that is fast to compile. To achieve “fast, memory safe, thread safe”, Graydon was ready to trade off everything else.
To see the value is what defines Rust, consider a counterfactual: what is a simple language that is easy to learn and fast to compile? It is Go. The value is what differentiates Rust and Go, not particular implementation choices.
According to these slides, initial Rust was a compiled and statically typed Erlang with C-style syntax and OCaml-style semantics :) I was really excited by that approach, but if I understood correctly, it was incompatible with fast calling to C (because of the GC and the growable stacks required for lightweight threads). Then seamless integration with C was prioritized, and as a consequence the GC and the lightweight threads had to be removed, amd without a GC the language needed another mechanism for automatic memory management which led to the borrow checker. Today’s Rust is very different from what was originally envisioned.
This is… not the whole story. Because Rust borrow checker preceded both removal of GC and green threads. In fact one of the hardest problem faced by design of Rust borrow checker was that it must work with GC. This is why Rust borrow checker is “extensible”, for example working fine with reference counted pointer implemented in the library.
Thanks for following-up on this. I didn’t know and that’s very interesting. What was the purpose of the borrow checked when there is a GC? For non-memory resources like file handles, etc.?
On traits and iterators: hypothetical memory safe C would insert bound checks like everyone else including Rust. The primary motivation behind Rust’s iterators is bound check elision, not syntax sugar. The primary motivation behind Rust’s traits is to support Rust’s iterators. Memory safe C without traits and iterators would be, say, 10% slower than Rust, or have lots of unsafe indexing.
I agree about RAII. Zig-style defer would work too. (The difference is that defer is not bound to type.)
I am aware it is almost unintelligible today without context, but Niko’s two posts in 2012 are “at the moment” record of this defining point in Rust history.
I personally love rust’s ML heritage and traits and iterators and RAII but I think it maybe turns off some hardcore low level and embedded developers, and they more than anyone are who we need to give memory safety to.
Tbh I’m kind of glad that it remains, and I’d be less enthusiastic about Rust if it wasn’t! I also think it’s really nice to bring these ideas to more systems programmers, who may have never been exposed to ML-style languages. It also makes it easier for languages that come after Rust to bring even more influences from ML into the mainstream (say, module systems for example).
I wonder if a “C with borrowck” is possible and what that looks like.
Cyclone was a research “safe C” language that might be of interest. Its region analysis has been cited as a predecessor/influence on the borrow checker, from my understanding.
A little appreciated fact: Rust was largely built by students, and many of them interned at Mozilla.
People don’t appreciate how true this is. With just a tiny bit of exaggeration, nearly all implementation work of Rust was done by interns. Rust was so understaffed that staffs could barely do design work (and proof-of-concept prototypes). It only worked because Mozilla Research interns were stellar.
I think the first Mozilla Research staff who mostly worked on implementation is Alex Crichton, hired in 2013.
Dave also did a ton of work on the “ES6 module system” (the standard JavaScript modules we have today). From that blog post of his, you can see that one of the things he wanted was “Future-compatibility for macros”.
The first I’d heard of Rust was a talk at Northeastern about 10 or so years back, before Rust had a fixed syntax. Some of the talk went over my head, but I enjoyed hearing about the garbage collection model and some of the other ideas.
The talk began with an apologia: Mozilla has a mission to further the open internet; the primary tool for doing so is Firefox; Firefox needs to be competitive on speed; performance is increasingly limited by the difficulties of safe concurrency; the existing languages don’t support this; we need a new language.
I’m pretty sure that was Dave Herman, who was maybe a postdoc or something at the time? Anyway, it was very compelling. I’ve not actually ended up using Rust for much of anything since it’s not quite the tool I need, but I really appreciate it existing and being available. :-)
This is a neat backstory, glad to see more “behind the scenes” rust development.
To me, the person I feel doesn’t get enough credit (though he does get a lot) is Niko Matsakis. As I understand the progression of rust, it started as a higher level, green threaded ML variant of sorts, and ended as this low level systems programming language we know today. But the key thing that defines rust, I think, is the borrow checker ownership model, which I think is thanks mostly to Niko. So while Graydon gets the credit for creating rust, I almost feel that was a different language, and the true “father” of rust as we know it is Niko.
And then I get wondering what it would have been like had the language been designed around the borrow checker from the start, or if that had been bolted onto a different language. I wonder if a “C with borrowck” is possible and what that looks like. I personally love rust’s ML heritage and traits and iterators and RAII but I think it maybe turns off some hardcore low level and embedded developers, and they more than anyone are who we need to give memory safety to.
What is the key thing that defines Rust?
Borrow checker is one candidate, but that’s an implementation. I think the key thing that defines Rust is its value. Rust’s value is Graydon’s contribution. Yes, Rust had an extremely different implementation, but it always had the same value. At least from the first public release to 1.0.
The current website says “Rust is a language empowering everyone to build reliable and efficient software”, but that’s post-1.0 change. (I actually consider this the most significant post-1.0 change. I think it was almost a coup.)
The previous website says “Rust is a systems programming language that runs blazingly fast, prevents segfaults, and guarantees thread safety”. That’s it. That’s Graydon’s contribution. It implies, Rust is not a simple language. Rust is not a language that is easy to learn. Rust is not a language that is fast to compile. To achieve “fast, memory safe, thread safe”, Graydon was ready to trade off everything else.
To see the value is what defines Rust, consider a counterfactual: what is a simple language that is easy to learn and fast to compile? It is Go. The value is what differentiates Rust and Go, not particular implementation choices.
A useful historic link about language values would be the first slide deck on Rust: http://venge.net/graydon/talks/intro-talk-2.pdf
According to these slides, initial Rust was a compiled and statically typed Erlang with C-style syntax and OCaml-style semantics :) I was really excited by that approach, but if I understood correctly, it was incompatible with fast calling to C (because of the GC and the growable stacks required for lightweight threads). Then seamless integration with C was prioritized, and as a consequence the GC and the lightweight threads had to be removed, amd without a GC the language needed another mechanism for automatic memory management which led to the borrow checker. Today’s Rust is very different from what was originally envisioned.
This is… not the whole story. Because Rust borrow checker preceded both removal of GC and green threads. In fact one of the hardest problem faced by design of Rust borrow checker was that it must work with GC. This is why Rust borrow checker is “extensible”, for example working fine with reference counted pointer implemented in the library.
Thanks for following-up on this. I didn’t know and that’s very interesting. What was the purpose of the borrow checked when there is a GC? For non-memory resources like file handles, etc.?
Thread safety
Absolutely. I forgot about this: https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html.
On traits and iterators: hypothetical memory safe C would insert bound checks like everyone else including Rust. The primary motivation behind Rust’s iterators is bound check elision, not syntax sugar. The primary motivation behind Rust’s traits is to support Rust’s iterators. Memory safe C without traits and iterators would be, say, 10% slower than Rust, or have lots of unsafe indexing.
I agree about RAII. Zig-style defer would work too. (The difference is that defer is not bound to type.)
would like to read the blog post version of this.
I am aware it is almost unintelligible today without context, but Niko’s two posts in 2012 are “at the moment” record of this defining point in Rust history.
Imagine never hearing the phrase aliasable, mutable again (November 2012) is about semantics of borrowing, and Lifetime notation (December 2012) is about syntax of borrowing. Note: none of eight(!) options discussed in syntax post is current syntax, although option 6 is close.
Tbh I’m kind of glad that it remains, and I’d be less enthusiastic about Rust if it wasn’t! I also think it’s really nice to bring these ideas to more systems programmers, who may have never been exposed to ML-style languages. It also makes it easier for languages that come after Rust to bring even more influences from ML into the mainstream (say, module systems for example).
Cyclone was a research “safe C” language that might be of interest. Its region analysis has been cited as a predecessor/influence on the borrow checker, from my understanding.
People don’t appreciate how true this is. With just a tiny bit of exaggeration, nearly all implementation work of Rust was done by interns. Rust was so understaffed that staffs could barely do design work (and proof-of-concept prototypes). It only worked because Mozilla Research interns were stellar.
I think the first Mozilla Research staff who mostly worked on implementation is Alex Crichton, hired in 2013.
Dave also did a ton of work on the “ES6 module system” (the standard JavaScript modules we have today). From that blog post of his, you can see that one of the things he wanted was “Future-compatibility for macros”.
Thanks, Dave Herman.
Keep Rust’s “behind the scenes” article coming. Happy to know it.
I don’t know how old Herman is, but I aspire to this quiet, gentle method of influence more and more as I get older.
Mostly because I’m not sure other methods really work. Lord knows I’ve tried.
The first I’d heard of Rust was a talk at Northeastern about 10 or so years back, before Rust had a fixed syntax. Some of the talk went over my head, but I enjoyed hearing about the garbage collection model and some of the other ideas.
The talk began with an apologia: Mozilla has a mission to further the open internet; the primary tool for doing so is Firefox; Firefox needs to be competitive on speed; performance is increasingly limited by the difficulties of safe concurrency; the existing languages don’t support this; we need a new language.
I’m pretty sure that was Dave Herman, who was maybe a postdoc or something at the time? Anyway, it was very compelling. I’ve not actually ended up using Rust for much of anything since it’s not quite the tool I need, but I really appreciate it existing and being available. :-)