I love Rust, I'm a fan of writing it and I love the tooling. And I love to see it's (hopefully) getting more popular. Despite this, I'm not sure if "won" is the right word because to my very uneducated eyes there is still considerable amount of Rust not succeeding. Admittedly I don't write so much Rust (I should do more!) but when I do it always baffles me how tons of the libraries recommended online are ghost town. There are some really useful Rust libraries out there that weren't maintained for many years. It still feels like Rust ecosystem is not quite there to be called a "successful" language. Am I wrong? This is really not a criticism of Rust per se, I'm curious about the answer myself. I want to dedicate so much more time and resources on Rust, but I'm worries 5 to 10 years from now everything will be unmaintained. E.g. Haskell had a much more vibrant community before Rust came and decent amount of Haskellers moved to Rust.
I don't even write in Rust, yet I'm curious if those libraries you talk about are truly in "abandoned" state and not simply in "done" state? Some languages somehow managed to build thriving ecosystems of libraries where they don't require constant attention and perpetual churn like in JS and Python. I see it too often e.g., in Clojure, where lib authors even have to add "maintenance disclaimers" noting that the lib is good for what it was designed for and there are no plans to add new features and no known bugs or critical dependencies found, and the lib is not abandoned, and they update those notes periodically, just for the sake of showing any git activity.
No, many are truly abandoned.
I have this all the time. Any new rust project and you have to wade through a bunch of once-great crates.
But that's because rust is new. The initial surge over produced solutions to, say binary serialization, and under produced, say, good geodesy libraries. And many many were abandoned. Go to any of the "are we X yet" sites and you'll see many crates that are clearly not finished or advancing which were recently considered SoA.
Any library in Rust comes with Cargo.toml file listing dependencies and their versions. Rust build system allows to use later versions of the libraries so presumably an application that uses an old library will have dependencies for the library updated.
The problem is that sometimes library may need to pin a dependency version. Or a dependency was released with a newer major version update and do not back-port security fixes to older versions.
So one cannot just use an old library. Its dependency list must carefully considered.
Now this problem exists with any package management system. But in Rust it is more visible as the language still evolves quickly with non-trivial new features released often.
Then the library authors may want to use newer language features on their API. Then they simply bump the library mayor version and maintain only that. So an old dependencies will not get updates.
> The problem is that sometimes library may need to pin a dependency version.
We on the Cargo team have been working to educate people on the problems with pinning in Cargo.toml instead of relying on Cargo.lock
> Then the library authors may want to use newer language features on their API. Then they simply bump the library mayor version and maintain only that. So an old dependencies will not get updates.
Thankfully, the ecosystem has mostly settled on build requirements not being subject to SemVer and bump Rust versions in compatible releases. There are a few hold outs.
I agree with the sentiment somewhat. Some rust libraries are dying, while some great new ones thrive (recently found iroh and wgpu to name a few). Everyone wants to write a game engine or some fun project and then abandon it, but no one wants to write a game. No application software has really "cemented" itself in the global ecosystem. Except for maybe ripgrep?
I would like to see support for more compilers (https://rust-gcc.github.io/), more interoperability with C/C++, better support for cross-compilation. Maybe less reliance on crates.io, static linking, and permissive licenses.
Still, I see Rust as the natural progression from C++. It has enough momentum to flatten all competitors (Carbon, Zig, Nim, Go) except scripting languages
> Still, I see Rust as the natural progression from C++
I don't; Rust has its niche but currently can't replace C++ everywhere.
From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees), for example retained mode GUIs, game engines, intrusive lists in general, non-owning pointers of subobjects part of the same forever-lived singleton, etc.
> Go
To displace Go you must also displace Kubernetes and its ecosystem (unlikely, k8s is such a convenient tool), or have k8s move away from Go (not gonna happen considering who developed both)
Things that live forever can be immutably borrowed, no problem.
So rather than a non-owning pointer, you'd just use a &'static here - the immutable borrow which (potentially) lives forever
Years ago it was tricky to write the "forever, once initialized" type, you'd need a third party crate to do it stably. But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever.
[If you need to specify some runtime parameters later, but still only initialize once and re-use you want OnceLock not LazyLock, the OnceLock is allowed to say there isn't a value yet]
Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one. They're like the snorkel on the 4x4 I see parked in my street. I'd be surprised if they've ever driven it on a muddy field, much less anywhere the snorkel would help.
A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
> intrusive lists in general
Not quite an intrusive list, but a particular data structure that's often called "intrusive" is a map where keys borrow from values. This turns out to be a super useful pattern.
Note that the signature here is `const key_type & operator()(const value_type &)`, or in Rust terms `fn key(&self) -> &Self::Key`. This means that the key must exist in a concrete form inside the value -- it is impossible to have keys that borrow from multiple fields within the value, for example.
At Oxide, I recently wrote and released https://docs.rs/iddqd, which provides similar maps. With iddqd, the signature is `fn key(&self) -> Self::Key<'_>`, which means that iddqd does allow you to borrow from multiple fields to form the key. See the ArtifactKey example under https://docs.rs/iddqd/latest/iddqd/#examples.
k8s was originally java, iirc
I find a lot of Rust libraries "seem" dead, based on github activity, but looking into it, they are actively used in many projects. I think Rust projects just tend to have less open issues, and don't need to be maintained as often. This is also the case internally at my company.
Rust will not "flatten" Go. They have some overlap but generally don't serve the same purpose and don't appeal to the same crowd. Go's popularity is undeniable, both in open source and in the industry. Outside of major shops and the odd shady Fintech startup, there are still very little Rust jobs out there. It's not necessarily bad, it's just the nature of it. Rust adoption is a slow thing because it addresses problems faced by slow moving software.
Go jobs are not that popular either especially outside US. Java is way more popular and with recent improvements on JDK Go does not offer that match advantages over it.
And compared with Go Java is fully memory-safe and have independent implementations.
I think you can say Rust won. There's enough investment from big tech and enough demonstrated value that it won't go away. And compared to functional languages with similarly sophisticated type systems? Rust has gained more users in the past 10 years than probably all of those other languages combined. That's not a fluke. Rust has pulled off making functional programming mainstream
By any standard of language development rust "won" in that a decade after creation it has a thriving ecosystem and companies using it exclusively. The White House named it by name.
I would say it won like it won the lottery, not like it won the tournament.
It's quite the opposite. The number of high-quality maintained libraries is growing.
Rust keeps growing exponentially, but by Sturgeon's law for every one surviving library you're always going to have 9 crap projects that aren't going to make it. Unfortunately, crates.io sorts by keyword relevance, not by quality or freshness of the library, so whatever you search for, you're going to see 90% of crap.
There was always a chunk of libraries destined for the dustbin, but it wasn't obvious in the early days when all Rust libraries were new. But now Rust has survived long enough to outlive waves of early adopter libraries, and grow pile of obviously dead libraries. The ecosystem is so large that the old part is large too.
Rust is now mainstream, so it's not a dozen libraries made by dedicated early adopters any more. People learning Rust publish their hello world toys, class assignments, their first voxel renderer they call a game engine. Startups drop dozens of libraries for their "ecosystem". Rust also lived through the peak of the cryptocurrency hype, so all these moon-going coins, smart contract VMs and NFTs exchanges now have a graveyard on crates.io.
When you run into dead libraries in Python or Java you don't think these languages are dying, it's just the particular libraries that didn't make it. JavaScript has fads and mass extinctions, and keeps going strong. Rust is old enough that it too has dead libraries, and big enough that it has both a large collection of decade-old libraries, as well as fads and fashions that come and go.
It's such a surprising dichotomy! Rust tooling, language and low-level capability makes it my top choice in several domains. It strikes me as the best tool available in high-performance and low-level domains. I contrast this with your observation: most of the open-source software (libraries generally) I see in rust are of poor quality.
I'm building a structural biology ecosystem in rust, split out into several libs, and a GUI program. Molecular dynamics, file format interop, API interaction, 3D viewer/dashboard/manipulation etc. I also do embedded in rust for work and personal projects. In both of these domains (High-performance scientific programming/GUI+3D, and embedded), I have had to write my own tooling. Nascent tools exist, but they are of too poor quality to use; e.g. easier to rewrite than attempt to work around the limitations of.
I'm at a loss. When I talk to people online about embedded rust, I find people discussing design patterns I think are high-friction (Async and typestates), and few people describe projects.
I think part of the problem is that it has acquired a group of people who design APIs and write libs without applying these libs to practical problems, which would expose their shortcomings.
You're last quote hits the nail on the head. I've found that good libraries are written by people actually solving the problem and then open sourcing it. pytorch, numpy, eigen, ros, openssl, etc. these all came from being trying to actually solve specific problems.
I think rust will get those libraries, but it takes time. Rust is still young compared to languages with a large amount of useful libraries. The boost project in c++ started in the 90s for example. It just takes time.
Boost is basically why I hate C++ but yes your point is entirely correct.
I write rust every day for a niche application that SHOULD be on paper completely trivial given advertised crates. But I constantly run into amateur hour math/correctness mistakes because nobody is using this stuff in daily user-serving production except apparently us. Some of this stuff should just be inexcusable.
One time I filed a bug report the maintainers response I got was "well I'm not familiar with X" where X was precisely what the library is advertised to do.
And yet they are fine rewriting the API every couple months.
This is early stage. The next wave of open source from companies giving back their work is going to be excellent.
I've been writing Rust professionally for 3+ years and, to me, Rust has won.
These days I write almost everything in Rust and there are only two outlier situations;
- Environments where I can't use Rust effectively. Web (wasm is great but it's not there yet), Apple, Cloudflare workers/Cloudfront edge functions.
- Use cases where there aren't good tools for Rust (like web scraping, pdf manipulation, that sort of thing)
I would guess the intent is that it won the argument. In 2015 if you'd asked WG21 why you can't have this model of safety for C++ you'd be told it's a pipe dream and they only standardize things which can be realised.
Because we won the argument now that doesn't work. When you say "it's a pipe dream" you're either ignorant or a liar, so, in 2025 WG21 didn't say this can't be realised - when they were shown proposals to do exactly this - they said well, we think we can achieve the same goals via a different route which suits us better, we just need more time.
Whether you believe that or not is a different conversation, but Rust won the argument.
Rust will when when I can finally match through boxes.
The talk touches on this notion specifically. The author notes that it's intentionally clickbait.
I personally would love to see a heavily moderated, curated, security hardened crates repository as an alternative to crates.io that contains only well-maintained, security audited, organizationally vetted crates.
For organizations that have regulatory, safety, strong security etc concerns (a market Rust is a natural fit for) this could be critically important. But even more so I would just use it. I am tired of my `cargo tree` rapidly turning into an exploding maze. I don't want 3 different MD5 or rand or cryptography or http packages used in one static linkage, and I don't want them bringing in an exploding maze of transitive dependencies of their own.
Are you aware of https://lib.rs/ ? Not "heavily", and a catalogue rather than a repository, but it's opinionated and curated.
Nice! I've wanted to give a similar talk. My thesis is that Rust won on usability above all else. If you look at the semantics of Rust, it's essentially an ML style language with typeclasses and linear types. In some alternate history that's a PhD thesis by someone at Inria that exactly 4 people use. But by making the language actually usable with good errors, familiar syntax (yes, syntax matters!), and documentation, Rust got users. I don't want to get into an in depth comparison but if you look at the documentation of even the most popular functional languages, it's not even close. And they've had a head start of decades!
I was wondering where I recognized your name before, before I realized you're the linebender guy.
> "How Rust Won"
I love Rust, I'm a fan of writing it and I love the tooling. And I love to see it's (hopefully) getting more popular. Despite this, I'm not sure if "won" is the right word because to my very uneducated eyes there is still considerable amount of Rust not succeeding. Admittedly I don't write so much Rust (I should do more!) but when I do it always baffles me how tons of the libraries recommended online are ghost town. There are some really useful Rust libraries out there that weren't maintained for many years. It still feels like Rust ecosystem is not quite there to be called a "successful" language. Am I wrong? This is really not a criticism of Rust per se, I'm curious about the answer myself. I want to dedicate so much more time and resources on Rust, but I'm worries 5 to 10 years from now everything will be unmaintained. E.g. Haskell had a much more vibrant community before Rust came and decent amount of Haskellers moved to Rust.
I don't even write in Rust, yet I'm curious if those libraries you talk about are truly in "abandoned" state and not simply in "done" state? Some languages somehow managed to build thriving ecosystems of libraries where they don't require constant attention and perpetual churn like in JS and Python. I see it too often e.g., in Clojure, where lib authors even have to add "maintenance disclaimers" noting that the lib is good for what it was designed for and there are no plans to add new features and no known bugs or critical dependencies found, and the lib is not abandoned, and they update those notes periodically, just for the sake of showing any git activity.
No, many are truly abandoned.
I have this all the time. Any new rust project and you have to wade through a bunch of once-great crates.
But that's because rust is new. The initial surge over produced solutions to, say binary serialization, and under produced, say, good geodesy libraries. And many many were abandoned. Go to any of the "are we X yet" sites and you'll see many crates that are clearly not finished or advancing which were recently considered SoA.
Any library in Rust comes with Cargo.toml file listing dependencies and their versions. Rust build system allows to use later versions of the libraries so presumably an application that uses an old library will have dependencies for the library updated.
The problem is that sometimes library may need to pin a dependency version. Or a dependency was released with a newer major version update and do not back-port security fixes to older versions.
So one cannot just use an old library. Its dependency list must carefully considered.
Now this problem exists with any package management system. But in Rust it is more visible as the language still evolves quickly with non-trivial new features released often.
Then the library authors may want to use newer language features on their API. Then they simply bump the library mayor version and maintain only that. So an old dependencies will not get updates.
> The problem is that sometimes library may need to pin a dependency version.
We on the Cargo team have been working to educate people on the problems with pinning in Cargo.toml instead of relying on Cargo.lock
> Then the library authors may want to use newer language features on their API. Then they simply bump the library mayor version and maintain only that. So an old dependencies will not get updates.
Thankfully, the ecosystem has mostly settled on build requirements not being subject to SemVer and bump Rust versions in compatible releases. There are a few hold outs.
I agree with the sentiment somewhat. Some rust libraries are dying, while some great new ones thrive (recently found iroh and wgpu to name a few). Everyone wants to write a game engine or some fun project and then abandon it, but no one wants to write a game. No application software has really "cemented" itself in the global ecosystem. Except for maybe ripgrep?
I would like to see support for more compilers (https://rust-gcc.github.io/), more interoperability with C/C++, better support for cross-compilation. Maybe less reliance on crates.io, static linking, and permissive licenses.
Still, I see Rust as the natural progression from C++. It has enough momentum to flatten all competitors (Carbon, Zig, Nim, Go) except scripting languages
> Still, I see Rust as the natural progression from C++
I don't; Rust has its niche but currently can't replace C++ everywhere.
From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees), for example retained mode GUIs, game engines, intrusive lists in general, non-owning pointers of subobjects part of the same forever-lived singleton, etc.
> Go
To displace Go you must also displace Kubernetes and its ecosystem (unlikely, k8s is such a convenient tool), or have k8s move away from Go (not gonna happen considering who developed both)
Things that live forever can be immutably borrowed, no problem.
So rather than a non-owning pointer, you'd just use a &'static here - the immutable borrow which (potentially) lives forever
Years ago it was tricky to write the "forever, once initialized" type, you'd need a third party crate to do it stably. But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever.
[If you need to specify some runtime parameters later, but still only initialize once and re-use you want OnceLock not LazyLock, the OnceLock is allowed to say there isn't a value yet]
Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one. They're like the snorkel on the 4x4 I see parked in my street. I'd be surprised if they've ever driven it on a muddy field, much less anywhere the snorkel would help.
A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
> intrusive lists in general
Not quite an intrusive list, but a particular data structure that's often called "intrusive" is a map where keys borrow from values. This turns out to be a super useful pattern.
https://www.boost.org/doc/libs/1_59_0/doc/html/boost/intrusi...
Note that the signature here is `const key_type & operator()(const value_type &)`, or in Rust terms `fn key(&self) -> &Self::Key`. This means that the key must exist in a concrete form inside the value -- it is impossible to have keys that borrow from multiple fields within the value, for example.
At Oxide, I recently wrote and released https://docs.rs/iddqd, which provides similar maps. With iddqd, the signature is `fn key(&self) -> Self::Key<'_>`, which means that iddqd does allow you to borrow from multiple fields to form the key. See the ArtifactKey example under https://docs.rs/iddqd/latest/iddqd/#examples.
k8s was originally java, iirc
I find a lot of Rust libraries "seem" dead, based on github activity, but looking into it, they are actively used in many projects. I think Rust projects just tend to have less open issues, and don't need to be maintained as often. This is also the case internally at my company.
Rust will not "flatten" Go. They have some overlap but generally don't serve the same purpose and don't appeal to the same crowd. Go's popularity is undeniable, both in open source and in the industry. Outside of major shops and the odd shady Fintech startup, there are still very little Rust jobs out there. It's not necessarily bad, it's just the nature of it. Rust adoption is a slow thing because it addresses problems faced by slow moving software.
Go jobs are not that popular either especially outside US. Java is way more popular and with recent improvements on JDK Go does not offer that match advantages over it.
And compared with Go Java is fully memory-safe and have independent implementations.
I think you can say Rust won. There's enough investment from big tech and enough demonstrated value that it won't go away. And compared to functional languages with similarly sophisticated type systems? Rust has gained more users in the past 10 years than probably all of those other languages combined. That's not a fluke. Rust has pulled off making functional programming mainstream
By any standard of language development rust "won" in that a decade after creation it has a thriving ecosystem and companies using it exclusively. The White House named it by name.
I would say it won like it won the lottery, not like it won the tournament.
It's quite the opposite. The number of high-quality maintained libraries is growing.
Rust keeps growing exponentially, but by Sturgeon's law for every one surviving library you're always going to have 9 crap projects that aren't going to make it. Unfortunately, crates.io sorts by keyword relevance, not by quality or freshness of the library, so whatever you search for, you're going to see 90% of crap.
There was always a chunk of libraries destined for the dustbin, but it wasn't obvious in the early days when all Rust libraries were new. But now Rust has survived long enough to outlive waves of early adopter libraries, and grow pile of obviously dead libraries. The ecosystem is so large that the old part is large too.
https://lib.rs/stats#crate-time-in-dev
Rust is now mainstream, so it's not a dozen libraries made by dedicated early adopters any more. People learning Rust publish their hello world toys, class assignments, their first voxel renderer they call a game engine. Startups drop dozens of libraries for their "ecosystem". Rust also lived through the peak of the cryptocurrency hype, so all these moon-going coins, smart contract VMs and NFTs exchanges now have a graveyard on crates.io.
When you run into dead libraries in Python or Java you don't think these languages are dying, it's just the particular libraries that didn't make it. JavaScript has fads and mass extinctions, and keeps going strong. Rust is old enough that it too has dead libraries, and big enough that it has both a large collection of decade-old libraries, as well as fads and fashions that come and go.
It's such a surprising dichotomy! Rust tooling, language and low-level capability makes it my top choice in several domains. It strikes me as the best tool available in high-performance and low-level domains. I contrast this with your observation: most of the open-source software (libraries generally) I see in rust are of poor quality.
I'm building a structural biology ecosystem in rust, split out into several libs, and a GUI program. Molecular dynamics, file format interop, API interaction, 3D viewer/dashboard/manipulation etc. I also do embedded in rust for work and personal projects. In both of these domains (High-performance scientific programming/GUI+3D, and embedded), I have had to write my own tooling. Nascent tools exist, but they are of too poor quality to use; e.g. easier to rewrite than attempt to work around the limitations of.
I'm at a loss. When I talk to people online about embedded rust, I find people discussing design patterns I think are high-friction (Async and typestates), and few people describe projects.
I think part of the problem is that it has acquired a group of people who design APIs and write libs without applying these libs to practical problems, which would expose their shortcomings.
You're last quote hits the nail on the head. I've found that good libraries are written by people actually solving the problem and then open sourcing it. pytorch, numpy, eigen, ros, openssl, etc. these all came from being trying to actually solve specific problems.
I think rust will get those libraries, but it takes time. Rust is still young compared to languages with a large amount of useful libraries. The boost project in c++ started in the 90s for example. It just takes time.
Boost is basically why I hate C++ but yes your point is entirely correct.
I write rust every day for a niche application that SHOULD be on paper completely trivial given advertised crates. But I constantly run into amateur hour math/correctness mistakes because nobody is using this stuff in daily user-serving production except apparently us. Some of this stuff should just be inexcusable.
One time I filed a bug report the maintainers response I got was "well I'm not familiar with X" where X was precisely what the library is advertised to do.
And yet they are fine rewriting the API every couple months.
This is early stage. The next wave of open source from companies giving back their work is going to be excellent.
I've been writing Rust professionally for 3+ years and, to me, Rust has won.
These days I write almost everything in Rust and there are only two outlier situations;
- Environments where I can't use Rust effectively. Web (wasm is great but it's not there yet), Apple, Cloudflare workers/Cloudfront edge functions.
- Use cases where there aren't good tools for Rust (like web scraping, pdf manipulation, that sort of thing)
I would guess the intent is that it won the argument. In 2015 if you'd asked WG21 why you can't have this model of safety for C++ you'd be told it's a pipe dream and they only standardize things which can be realised.
Because we won the argument now that doesn't work. When you say "it's a pipe dream" you're either ignorant or a liar, so, in 2025 WG21 didn't say this can't be realised - when they were shown proposals to do exactly this - they said well, we think we can achieve the same goals via a different route which suits us better, we just need more time.
Whether you believe that or not is a different conversation, but Rust won the argument.
Rust will when when I can finally match through boxes.
The talk touches on this notion specifically. The author notes that it's intentionally clickbait.
I personally would love to see a heavily moderated, curated, security hardened crates repository as an alternative to crates.io that contains only well-maintained, security audited, organizationally vetted crates.
For organizations that have regulatory, safety, strong security etc concerns (a market Rust is a natural fit for) this could be critically important. But even more so I would just use it. I am tired of my `cargo tree` rapidly turning into an exploding maze. I don't want 3 different MD5 or rand or cryptography or http packages used in one static linkage, and I don't want them bringing in an exploding maze of transitive dependencies of their own.
Are you aware of https://lib.rs/ ? Not "heavily", and a catalogue rather than a repository, but it's opinionated and curated.
Nice! I've wanted to give a similar talk. My thesis is that Rust won on usability above all else. If you look at the semantics of Rust, it's essentially an ML style language with typeclasses and linear types. In some alternate history that's a PhD thesis by someone at Inria that exactly 4 people use. But by making the language actually usable with good errors, familiar syntax (yes, syntax matters!), and documentation, Rust got users. I don't want to get into an in depth comparison but if you look at the documentation of even the most popular functional languages, it's not even close. And they've had a head start of decades!
I was wondering where I recognized your name before, before I realized you're the linebender guy.
Hello! Big fan of your UI research
Slides from video description
https://docs.google.com/presentation/d/1SoDsm_m_pb_gS6Y98Hgh...
Thanks! We've put that in the thread header.