Rust Creator Graydon Hoare Thanks Its Many Stakeholders - and Mozilla - on Rust's 10th Anniversary (rustfoundation.org) 23
Thursday was Rust's 10-year anniversary for its first stable release. "To say I'm surprised by its trajectory would be a vast understatement," writes Rust's original creator Graydon Hoare. "I can only thank, congratulate, and celebrate everyone involved... In my view, Rust is a story about a large community of stakeholders coming together to design, build, maintain, and expand shared technical infrastructure."
It's a story with many actors:
- The population of developers the language serves who express their needs and constraints through discussion, debate, testing, and bug reports arising from their experience writing libraries and applications.
- The language designers and implementers who work to satisfy those needs and constraints while wrestling with the unexpected consequences of each decision.
- The authors, educators, speakers, translators, illustrators, and others who work to expand the set of people able to use the infrastructure and work on the infrastructure.
- The institutions investing in the project who provide the long-term funding and support necessary to sustain all this work over decades.
All these actors have a common interest in infrastructure.
Rather than just "systems programming", Hoare sees Rust as a tool for building infrastructure itself, "the robust and reliable necessities that enable us to get our work done" — a wide range that includes everything from embedded and IoT systems to multi-core systems. So the story of "Rust's initial implementation, its sustained investment, and its remarkable resonance and uptake all happened because the world needs robust and reliable infrastructure, and the infrastructure we had was not up to the task." Put simply: it failed too often, in spectacular and expensive ways. Crashes and downtime in the best cases, and security vulnerabilities in the worst. Efficient "infrastructure-building" languages existed but they were very hard to use, and nearly impossible to use safely, especially when writing concurrent code. This produced an infrastructure deficit many people felt, if not everyone could name, and it was growing worse by the year as we placed ever-greater demands on computers to work in ever more challenging environments...
We were stuck with the tools we had because building better tools like Rust was going to require an extraordinary investment of time, effort, and money. The bootstrap Rust compiler I initially wrote was just a few tens of thousands of lines of code; that was nearing the limits of what an unfunded solo hobby project can typically accomplish. Mozilla's decision to invest in Rust in 2009 immediately quadrupled the size of the team — it created a team in the first place — and then doubled it again, and again in subsequent years. Mozilla sustained this very unusual, very improbable investment in Rust from 2009-2020, as well as funding an entire browser engine written in Rust — Servo — from 2012 onwards, which served as a crucial testbed for Rust language features.
Rust and Servo had multiple contributors at Samsung, Hoare acknowledges, and Amazon, Facebook, Google, Microsoft, Huawei, and others "hired key developers and contributed hardware and management resources to its ongoing development." Rust itself "sits atop LLVM" (developed by researchers at UIUC and later funded by Apple, Qualcomm, Google, ARM, Huawei, and many other organizations), while Rust's safe memory model "derives directly from decades of research in academia, as well as academic-industrial projects like Cyclone, built by AT&T Bell Labs and Cornell."
And there were contributions from "interns, researchers, and professors at top academic research programming-language departments, including CMU, NEU, IU, MPI-SWS, and many others." JetBrains and the Rust-Analyzer OpenCollective essentially paid for two additional interactive-incremental reimplementations of the Rust frontend to provide language services to IDEs — critical tools for productive, day-to-day programming. Hundreds of companies and other institutions contributed time and money to evaluate Rust for production, write Rust programs, test them, file bugs related to them, and pay their staff to fix or improve any shortcomings they found. Last but very much not least: Rust has had thousands and thousands of volunteers donating years of their labor to the project. While it might seem tempting to think this is all "free", it's being paid for! Just less visibly than if it were part of a corporate budget.
All this investment, despite the long time horizon, paid off. We're all better for it.
He looks ahead with hope for a future with new contributors, "steady and diversified streams of support," and continued reliability and compatability (including "investment in ever-greater reliability technology, including the many emerging formal methods projects built on Rust.")
And he closes by saying Rust's "sustained, controlled, and frankly astonishing throughput of work" has "set a new standard for what good tools, good processes, and reliable infrastructure software should be like.
"Everyone involved should be proud of what they've built."
- The population of developers the language serves who express their needs and constraints through discussion, debate, testing, and bug reports arising from their experience writing libraries and applications.
- The language designers and implementers who work to satisfy those needs and constraints while wrestling with the unexpected consequences of each decision.
- The authors, educators, speakers, translators, illustrators, and others who work to expand the set of people able to use the infrastructure and work on the infrastructure.
- The institutions investing in the project who provide the long-term funding and support necessary to sustain all this work over decades.
All these actors have a common interest in infrastructure.
Rather than just "systems programming", Hoare sees Rust as a tool for building infrastructure itself, "the robust and reliable necessities that enable us to get our work done" — a wide range that includes everything from embedded and IoT systems to multi-core systems. So the story of "Rust's initial implementation, its sustained investment, and its remarkable resonance and uptake all happened because the world needs robust and reliable infrastructure, and the infrastructure we had was not up to the task." Put simply: it failed too often, in spectacular and expensive ways. Crashes and downtime in the best cases, and security vulnerabilities in the worst. Efficient "infrastructure-building" languages existed but they were very hard to use, and nearly impossible to use safely, especially when writing concurrent code. This produced an infrastructure deficit many people felt, if not everyone could name, and it was growing worse by the year as we placed ever-greater demands on computers to work in ever more challenging environments...
We were stuck with the tools we had because building better tools like Rust was going to require an extraordinary investment of time, effort, and money. The bootstrap Rust compiler I initially wrote was just a few tens of thousands of lines of code; that was nearing the limits of what an unfunded solo hobby project can typically accomplish. Mozilla's decision to invest in Rust in 2009 immediately quadrupled the size of the team — it created a team in the first place — and then doubled it again, and again in subsequent years. Mozilla sustained this very unusual, very improbable investment in Rust from 2009-2020, as well as funding an entire browser engine written in Rust — Servo — from 2012 onwards, which served as a crucial testbed for Rust language features.
Rust and Servo had multiple contributors at Samsung, Hoare acknowledges, and Amazon, Facebook, Google, Microsoft, Huawei, and others "hired key developers and contributed hardware and management resources to its ongoing development." Rust itself "sits atop LLVM" (developed by researchers at UIUC and later funded by Apple, Qualcomm, Google, ARM, Huawei, and many other organizations), while Rust's safe memory model "derives directly from decades of research in academia, as well as academic-industrial projects like Cyclone, built by AT&T Bell Labs and Cornell."
And there were contributions from "interns, researchers, and professors at top academic research programming-language departments, including CMU, NEU, IU, MPI-SWS, and many others." JetBrains and the Rust-Analyzer OpenCollective essentially paid for two additional interactive-incremental reimplementations of the Rust frontend to provide language services to IDEs — critical tools for productive, day-to-day programming. Hundreds of companies and other institutions contributed time and money to evaluate Rust for production, write Rust programs, test them, file bugs related to them, and pay their staff to fix or improve any shortcomings they found. Last but very much not least: Rust has had thousands and thousands of volunteers donating years of their labor to the project. While it might seem tempting to think this is all "free", it's being paid for! Just less visibly than if it were part of a corporate budget.
All this investment, despite the long time horizon, paid off. We're all better for it.
He looks ahead with hope for a future with new contributors, "steady and diversified streams of support," and continued reliability and compatability (including "investment in ever-greater reliability technology, including the many emerging formal methods projects built on Rust.")
And he closes by saying Rust's "sustained, controlled, and frankly astonishing throughput of work" has "set a new standard for what good tools, good processes, and reliable infrastructure software should be like.
"Everyone involved should be proud of what they've built."
Re: (Score:2)
Don't hold back, tell us how you really feel.
Re: (Score:3)
Would this be the same infrastructure that gave rise to the internet and allowed people to collaborate in the first place to come up with this Me-Too language?
Greg Kroah-Hartman, linux kernel maintainer (-stable): [kernel.org]
As someone who has seen almost EVERY kernel bugfix and security issue for the past 15+ years (well hopefully all of them end up in the stable trees, we do miss some at times when maintainers/developers forget to mark them as bugfixes), and who sees EVERY kernel CVE issued, I think I can speak on this topic.
The majority of bugs (quantity, not quality/severity) we have are due to the stupid little corner cases in C that are totally gone in Rust. Things like simple overwrites of memory (not that rust can catch all of these by far), error path cleanups, forgetting to check error values, and use-after-free mistakes. That's why I'm wanting to see Rust get into the kernel, these types of issues just go away, allowing developers and maintainers more time to focus on the REAL bugs that happen (i.e. logic issues, race conditions, etc.)
You: "Me too . . . " and politics.
Whoever wrote this pile sounds like he went to the Trump school of telling it how it is.
Or a guy who knows that C can and has lead to bad code even under strict review policies. And he attempted to solve some of the issues by inventing Rust. But for you it was about Me too and politics. I guess when all you have is a hammer, everything must be a nail.
Re: (Score:2)
The goal of programming is to make beautiful, portable code, and some god-awful language that (a) only runs on a couple of platforms in the first place and (b) does not punish stupid programmers is not the answer. Like, if the worst 10% computer programmers woke up tomorrow and decided, you know what, I'm going to quit software and work in a kitchen or dig ditches or whatever, that would make things so much better. Why do you want to enable stupid programmers?
And how is any of that relevant to maintaining the linux kernel?
And enable bad engineering practices?
What are you talking about? If anything Rust enforces good practices by not allowing things that C allows that lead to bad code.
Pretty much the only testing that Linux gets is that the code compiles and is not obviously broken.
Again what are you talking about? People don't just slap things into Linux and no one does any testing.
This guy (and certainly not all Linux maintainers) would rather not do proper software engineering so that is why he likes Rust.
That is the EXACT opposite of what he said.
How many security holes does SQLite have? Not fucking many because they test it properly before release.
He is talking about C and Rust. Not SQLite. Please try to stay on topic.
Re: (Score:2)
What makes C beautiful are the rules. Like, having code that can run where sizeof(anything) = 1
Exposing you to multiple corner case bugs
where ints can be 16 bits,
Exposing you to more corner case bugs
where arithmetic can be 1s complement or 2s complement
Exposing you to yet more corner case bugs
where you can have big endian or little endian integers
The corner cases are really piling up
where the character set cannot even be assumed to be ASCII
Now you're overwhelmed by corner cases
The goal of programming is to make beautiful, portable code
That's unavoidably riddled with bugs and vulnerabilities because of all the untestable corner cases.
And this is before you've even gotten to the vast "undefined behavior" areas and pointer arithmetic bugs.
Why do you want to enable stupid programmers?
That's always the C apologists' argument. They think they are logical geniuses, but can't even fathom that having
Re: (Score:2)
I think you are both wrong.
If only your experience matched your arrogance (Score:2)
The goal of programming is to make beautiful, portable code, and some god-awful language that (a) only runs on a couple of platforms in the first place and (b) does not punish stupid programmers is not the answer. Like, if the worst 10% computer programmers woke up tomorrow and decided, you know what, I'm going to quit software and work in a kitchen or dig ditches or whatever, that would make things so much better. Why do you want to enable stupid programmers?
And enable bad engineering practices? Pretty much the only testing that Linux gets is that the code compiles and is not obviously broken. This guy (and certainly not all Linux maintainers) would rather not do proper software engineering so that is why he likes Rust. How many security holes does SQLite have? Not fucking many because they test it properly before release.
Nope...the goal of a professional programming is to solve the problems of those paying you. Beautiful code is not decided by programmers, but by those who write the checks...does it do what they need...reliably....with a reasonable cost of maintenance down the road. A lot of GREAT code is ugly AF to look at, often suboptimal, but easy to maintain...I basically just described the Java experience.
Regarding your "stupid programmers" elitism...fuck off. Want to know why we have stupid programmers?
We hav
Re: (Score:2)
Did you mean to call Rust a "pick-me language"? That fits with what you're saying, and would actually be a proper/funny use of slang.
Re: (Score:2)
I hear where you are coming from. But for sure Rust cannot be a Me-Too language because it has features that no other language has ever had. At least not outside of research. It's the first new language to offer something genuinely new and useful since C arrived.
You're clearly not a professional (Score:2)
Would this be the same infrastructure that gave rise to the internet and allowed people to collaborate in the first place to come up with this Me-Too language? Tell the guys who worked at DARPA that their infrastructure was crap and they didn't know what they were doing or maybe back in the 90s when the web was taking off and a lot of rust devs were still sitting on a potty and web servers advanced in leaps and bounds.
Whoever wrote this pile sounds like he went to the Trump school of telling it how it is.
Fuck off. Rust is a powerful tool and has the potential to not only give us better software, but reduce the carbon footprint of our IT infrastructure. It's the only memory-safe language that's faster than Java, plus it has the lowest power utilization of any memory-safe language. It's a FUCKTON faster than the steaming garbage heap that is Go....and not the performance disaster that Python or JavaScript is....and if you're one of those "real men write in C" type assholes, fuck off as well...there's a MAS
Re: (Score:2)
I think this is exaggerated. First, one can write memory safe code in C and have this formally verified and this also common in critical application areas, we lack good open-source tools though. But then, one can also use existing tools and good practices to write relatively safe code in C. The ideas that this is impossible for average is something which often repeated in this context, but there are also plenty of C projects with excellent security record. There is, of course, also a lot of bad or lega
"stable" (Score:3)
Given the explosive amount of expansion the language has gone through it has been stable in name only. Frankly, I consider the first actual stable release to be the one that conforms to a written specification. For Rust, the specification was only finalized a few months ago.
Re: (Score:2)
Yes and no. C was widely in use before it was formalised. and standardised. I see no reason therefore why you would criticise Rust for going through the same evolution.
Re: (Score:2)
1) C was very unstable before there was a formal standard.
2) Nobody here claimed C was stable before there was a formal standard.
3) Rust has a much larger feature set making it's instability that much higher.
I'm not criticizing Rust here, I'm saying the claim of stability is a load of bullshit.
Re: (Score:2)
The criticism is not about Rust going through the same evolution (it lacks alternative implementation though), but that it claims to be on same level as C in this respect before it is.
Re: (Score:2)
Certainly Rust has been up to C for five years or more.
Re: (Score:2)
Also, C is not stable to this very day. Move your code to a different architecture, OS or compiler and it will behave differently depending on whatever "implementation defined" features from the standard it uses or what non-standard compiler options and extensions it needs. It's a mess.
Re: (Score:2)
it will behave differently depending on whatever "implementation defined" features from the standard it uses
Implementation defined behavior occurs in every standardized language that has a multitude of implementations. The reason is that undefined behavior finally gets identified and nobody wants to change their compiler so it becomes an implementation defined feature.
what non-standard compiler options and extensions it needs.
If you're using non-standard features then you have already lost the portability game and should not be surprised. Non-standard features are another thing that occur as a result of having a multitude of implementations. Every compiler is competing t
Rust in linux. (Score:3)
I will say this as an electronics engineer who learned BASIC, COBOL, RPG-II, Pascal (in high-school) & C (@ Uni), got proficient enough in C to be a TA, and started using Linux in '95:
I do not see anything wrong with re-writing parts of userland in Rust.
I do not see anything wrong with re-writing Kernel Loadable Modules (i.e. drivers) in Rust
I do not see anything wrong with re-writing "kernel-adjacent" subsystems (say, the bootloader, or the init subsystem) in Rust.
I lack enough knowledge to emit an oppinion on rewriting parts of the kernel itself in Rust, nor about re-writing drivers that are added to the kernel @ compile time in Rust.
All the best luck for the lads and lasses @ Cannonical dealing with UUTILS and rs-sudo
Happy 10th anniversary to Rust the language, and to all the contrbutors over the years.