The diaspora
Mozilla laid off much of the Rust team in August 2020
- Hacker News discussion https://news.ycombinator.com/item?id=24143819
~everybody landed at a big tech company
Result: Rust knowledge well distributed around industry
No one company dominates
- In contrast to Java, Swift, Go, C#, Dart
Strong sense of collaboration & common mission
- You can really feel this at conferences
Have you actually contributed to the Go standard library?
Yes, there are people who don't work for Google and can +2 on changes, but you still need 2 Google employees to at least +1 on your change before it can be submitted. This is mentioned in the Contribution Guide [0] and is enforced by Gerrit.
> Finally, to be submitted, a change must have the involvement of two Google employees, either as the uploader of the change or as a reviewer voting at least Code-Review +1. This requirement is for compliance and supply chain security reasons.
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!
To be clear: Rust does not have linear types. Rust has affine types. An affine Goose can't destroyed more than once. However zero isn't more than one. A linear Goose must be destroyed exactly once. Austral would be an example of a language with linear types.
In C++ if we destroy this Goose twice, probably everything catches on fire, whoops.
In Rust or Austral if we attempt to destroy this Goose twice the code doesn't compile. No executable for you until you stop destroying the Goose twice.
In C++ or Rust if we forget to destroy the Goose, the Goose-destroying code never runs. Hope that wasn't important.
In Austral if we forget to destroy the Goose, the code doesn't compile. No executable for you until you ensure the Goose is destroyed.
Rust has a combo: people come for safety, stay for usability.
Languages struggle to win on usability alone, because outside of passion projects it's really hard to justify a rewrite of working software to get the same product, only with neater code.
But if the software also has a significant risk of being exploited, or is chronically unstable, or it's slow and making it multi-core risks making it unstable, then Rust has a stronger selling point. Management won't sign off a rewrite because sum types are so cool, but may sign off an investment into making their product faster and safer.
Generally speaking I was more prone to agreeing with Rust-haters, and thought the whole idea of how Rust lifetimes are implemented is flawed, and the borrow checker is needlessly restrictive. I also disagree with some other ideas like the overreliance on generics to do static dispatch leading to large executables and slow compiles.
To be clear I still think these criticisms are valid. However after using the language in production, I've come to realize these problems in practice are manageable. The langauge is nice, decently well supported, has a relatively rich ecosystem.
Every programming language/ecosystem is flawed in some way, and I think as an experienced dev you learn to deal with this.
It having an actual functioning npm-like package management and build system makes making multiplatform software trivial. Which is something about C++ that kills my desire to deal with that language on a voluntary basis.
The ecosystem is full of people who try to do their best and produce efficient code, and try to understand the underlying problem and the machine. It feels like it still has a culture of technical excellence, while most libraries seem to be also well organized and documented.
This is in contrast to JS people, who often try to throw together something as fast as possible, and then market the shit out of it to win internet points, or Java/C# people who overcomplicate and obfuscate code by sticking to these weird OOP design pattern principles where every solution needs to be smeared across 5 classes and design patterns.
Not sure if I would follow that point about usability. For me usability means also how usable it is to new people. How usable is the language to a foreign person compared to e.g. Python, Go or even Java - or if you want to mention functional languages like F#?
But besides that I am totally on your side, usability is great.
Here's an amusing anti-Rust talk: "Rust a language without poetry".[1] It's a reasonable critique, but the presentation is awful. It seems that someone took a paper and ran it through some AI program that provided text to speech and irrelevant images. Need to run it through a tool to extract the text, then discard the video.
"Every (lost) week spent refactoring to satisfy lifetime constraints..." Not wrong.
That was amusing. It felt like those AI ads that YouTube sometimes feeds me, where a perpetual preamble promises to have a point and to get to it, which might have something to do with toe fungus or restoring virility but you’ll never know because the actual point is to lull you into a trance-like state of perfect thoughtlessness.
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.
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.
I've complained about that in the 3D graphics area. But that's niche. Recently I had to write some webcrap, a web server responder that runs under Apache mod_fcgid.
I expected that area to Just Work. Works fine in Go, out of the box. There were about a half-dozen abandoned crates which sort of implemented that kind of server. I had to write one from scratch.[1]
The Rust compiler is great, but the crates... There are now enough of them to need curation. Some need to be moved to some obsolete status. Some need to make it to 1.0. Crates.io is starting to clog up with junk.
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 see it too often e.g., in Clojure, where lib authors even have to add "maintenance disclaimers"
I think this is a peculiarity of Clojure. Clojure is optimized for simplicity and as the saying goes: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
I don't use Clojure these days. Maybe I should revisit the language. It has some really nice ideas.
Two words: "depend a bot"... Okay, three words... Anyway, updating dependencies and fixing bugs is "maintenance", not "adding new features". From the project management perspective, the project is in "done" state, if it doesn't require new features.
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 can agree to an extent that API designers sometimes (often?) over engineer for imagined problems.
At the same time, I've been working on an embedded Rust project and trying Embassy for the first time and it is _amazing_.
First of all I've had good logging and debug support with probe-rs. Secondly, being able to do ergonomic DMA transfers with async/await syntax feels like cheating. The core goes to sleep until your transfer finishes and an interrupt fires which wakes up the core and continues your async state machine, which the compiler built for you from your async code.
Distinct tasks can be split up into separate async functions, the type system models ownership of singleton hardware well (you can't use Pin 8 for your SPI bus there, you already "moved" it to your I2S peripheral over there!), and it all comes together with pretty minimal RAM usage, efficient use of the hardware, and low power consumption if you're mostly waiting on data transfers.
I'd be happy to talk more about practical problems if you want to get specific.
Good observations! I think Embassy worked out because its creator built it with the goal of shipping smart door locks, so the components of it he uses for that workflow work well.
I think ownership sometimes works for the reason bring up: Catching errors. I suspect you will find cases where you are not as pleased you can't use something you moved elsewhere! In some cases the ownership semantics map smoothly to control over hardware; in others, it's not so good of a fit. I also suspect you are overestimating how difficult DMA and power management are without async. (In rust or otherwise) What you described is a ubiquitous embedded workflow, minus the state machine.
Yep, I can definitely imagine cases where ownership can get in the way of doing something esoteric, but at least there are escape hatches for that if needed.
> I also suspect you are overestimating how difficult DMA and power management are without async.
I probably am, but having ergonomic syntax to orchestrate it all feels like something I wouldn't want to give up, after experiencing it.
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.
I'm not sure how a programming language can win other than having a thriving ecosystem and seeing use, as you point out. The current USA government removed the “Back to the Building Blocks: A Path Toward Secure and Measurable Software.” report and fired the people responsible though. So for all we know the current White House might be betting on PHP.
As professional developers, however, I think there is also the job market to consider. It obviously depends on where you live in the world, but in my area there have been 0 Rust jobs for 5 years. There are plenty of C++ jobs, there are even a few Zig jobs once in a while. Go on the other hand has seen an explosive growth, though probably as a replacement for C# and Java rather than for C++.
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.
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.
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)
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.
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?
> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
The problem with retained mode GUIs is that, while the widget tree is, well, a a nice hierarchical tree, the widgets and the data model often need mutable references to each other, and it's these cross-references that break the tree-based ownership model of Rust.
> 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.
This corresponds to a C++ feature that has been added in C++11 (and other languages have this too AFAIK); good for libraries but but this has a runtime performance cost.
Since C++20 you can use constinit, or std::construct_at to avoid static initialization woes entirely
> 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.
True about C, and also true of most userspace applications.
However, the whole point of intrusive list (and other intrusive structures) is to flip the ownership relationship - the object owns the node, instead of the node owning the object. In other words, the intrusive list is a non-owning view over its elements. More importantly, they allow the same object to be present in multiple lists at once (as long as you add enough node hooks).
For example, you can have a pool-allocated Thread object that is simultaneously part of a queue of inactive threads of priority N, and also part of a wait queue for something else.
> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
Right, I conflated it with the other examples, my bad; there it's because of shared mutable state, children elements needing to update their parents, and lack of inheritance in Rust
> Since C++20 you can use constinit, or std::construct_at to avoid static initialization woes entirely
This is just yet another bad defaults situation. Yes, that's the correct behaviour and so it's what Rust's statics do, but it wasn't how C++ worked so they had to add this constinit keyword. LazyStatic is solving the other thing - where we don't need runtime parameters but we are doing work at runtime so we aren't truly constant.
I think people are still working out the best way to do GUIs and game engines in Rust, but I wouldn't say that's because it's impossible. It's just quite new.
It took decades to get a C++ GUI framework that was really nice (Qt) and even then it used MOC so wasn't pure C++.
Intrusive lists are quite niche and not a big deal.
I think people are working on improving the ergonomics for Rc<Refcell< etc.
So there are definitely some downsides, but also so many upsides. You could easily say C++ can't replace Rust in many areas because of X, Y, Z.
> From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees)
Yeah, non-hierarchical references don't really lend themselves to static safety enforcement, so the question is what kind of run-time support the language has for non-hierarchical references. But here Rust has a disadvantage in that its moves are (necessarily) trivial and destructive.
For example, the scpptool-enforced memory-safe subset of C++ has non-owning smart pointers that safely support non-hierarchical (and even cyclical) referencing.
They work by wrapping the target object's type in a transparent wrapper that adds a destructor that informs any targeting smart pointers that the object is about to become invalid (or, optionally, any other action that can ensure memory safety). (You can avoid needing to wrap the target object's type by using a "proxy" object.)
Since they're non-owning, these smart pointers don't impose any restrictions on when/where/how they, or their target objects, are allocated, and can be used more-or-less as drop-in replacements for raw pointers.
Unfortunately, this technique can't be duplicated in Rust. One reason being that in Rust, if an object is moved, its original memory location becomes invalid without any destructor/drop function being called. So there's no opportunity to inform any targeting (smart) pointers of the invalidation. So, as you noted, the options in Rust are less optimal. (Not just "ergonomically", but in terms of performance, memory efficiency, and/or correctness checking.) And they're intrusive. They require that the target objects be allocated in certain ways.
Rust's policy of moves being (necessarily) trivial and destructive has some advantages, but it is not required (or arguably even helpful) for achieving "minimal-overhead" memory safety. And it comes with this significant cost in terms of non-hierarchical references.
So it seems to me that, at least in theory, an enforced memory-safe subset of C++, that does not add any requirements regarding moves being trivial or destructive, would be a more natural progression from traditional C++.
> Yeah, non-hierarchical references don't really lend themselves to static safety enforcement, so the question is what kind of run-time support the language has for non-hierarchical references.
Yes. Back references are a big problem.
I just wrote a bidirectional transitive closure algorithm that uses many back references, with heavy use of Rc, RefCell, Weak, and ".borrow()". It's 100% safe rust.
This is the "proper" Rust way to write this sort of thing. The nice thing about doing it the "right" way was that, once it compiled, it needed few changes to work correctly. No mysterious errors at all.
But it took a lot of work to get it to compile. Some sections had to be rewritten to get the ownership plumbing right.
I put it up on the Rust forums for comments, and got replies that I should stop doing all that fancy stuff and just use indices into arrays.[1] Or arena allocation. Things that bypass the Rust ownership system. Those approaches would probably have more bugs.
(I'm starting to see a way to do compile time checking for this sort of thing. The basic concept is that run time borrows must be disjoint as to type, disjoint as to scope, or disjoint as to instance. The first is easy. The second requires inspecting the call chain, and there are problems with templates due to ambiguity over what a type parameter does in .borrow() activity. The third is almost a theorem proving problem, but if you restrict compile time checks for disjoint instances to a single function (or maybe a "class", a struct and its functions), it might be manageable. All this might take too much cleverness to use in practice. Too much time getting the ownership plumbing right, even with compiler support.
But I should write this up.)
> I put it up on the Rust forums for comments, and got replies that I should stop doing all that fancy stuff and just use indices into arrays.[1] Or arena allocation. Things that bypass the Rust ownership system. Those approaches would probably have more bugs.
I ran into this years ago as well. It was very unsatisfying. Maybe Rust is just missing a good GC type?
It's not an allocation problem. It's a back-reference problem. When struct A owns struct B, and B needs to be able to find A, that's surprisingly difficult to set up in Rust. Even for structures where B is inside of A's struct.
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 like modern Java and agree it's a much better language than Go and an excellent platform in general. But Java will not beat Go where small and fast native executables are required. The native story for Java will remain a sad one, builds being hyper slow (aot) or resulting in huge binaries (jlink).
Beyond a certain project size, GraalVM compiles to the same binary size as Go. Many k8s projects produce binary sizes of >100MB. I think this is because LOC in Go scales poorly.
Go's real edge over Java is in memory consumption, not in performance or binary size. Yet, this is also mostly true at the small-scale level. The edge again disappears for large projects needing large heaps.
If one needs a small and fast executable, then Rust should be used, not Go. I know a company that wished they would use Rust, not Go, for their services as poor Go performance and GC spikes made it a big headache.
You must be joking. Over 75% of software on CNCF is written in Go; these include tools ranging from CI/CD to metrics and monitoring. It may not be popular to write your enterprise applications but it is certainly very popular in cloud infrastructure
Quite serious, CNCF products are basically Docker and Kubernetes related, that isn't what actual companies care about when moving their compute workloads from in-house into AWS, Azure, GCP, Vercel, Nelify, while paying big boys money to consulting agencies.
Many of those products are startups looking for attention in podcasts interviews and the like, and barely part of any enterprise cloud projects.
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.
I feel like Rust hasn't won yet - it needs to transition from the cool technology people because of the hype, novelty and the clout it affords them to the pragmatic boring technology people use because it's the best tool for the job.
In this stage, the unique standout features are given a lot of limelight, and people are a bit more forgiving with usability failings and library shortcomings, as that can be fixed later.
If they fail, they'll be relegated to the 'perpetually misunderstood' pile, like Haskell has.
Node/Ts has made the transition a while ago, Go's ride was a bit more bumpy (most ppl agree the language is good, but channels are a bit of an acquired taste).
I think Rust is in the process of making the jump. I think language devs and library maintainers are a bit more responsive to the borrow checker usability gripes (rather than the knee-jerk 'you just don't get it' reaction) and the ecosystem expands in both depth and breadth. Imo the question of Rust making it is more of a 'when' than 'if', but it's not there yet.
Also there is a certain npm feeling, every time I try out some trendy project, endless list of crates being compiled, even more interesting is seeing some being compiled multiple times.
I agree it is a problem. Though in my experience it's still not as bad as NPM. I still know what most of the dependencies do, even when there are hundreds. And you usually get hundreds of dependencies only for things that simply do a lot. E.g. one of my projects has hundreds of dependencies but that's because it includes wasmtime, which feels fairly justified.
In NPM you often get thousands of dependencies for things that should be simple like Vue.
Another factor is that projects are often split into many crates for compile time & modularity reasons, e.g. Gix is dozens of crates.
The "two versions of a crate" is actually a great thing. In other ecosystems like Python you would be simply unable to build the project at all because you can only have one version of any dependency.
The one thing that I think is a big problem is where you have splits in the ecosystem, e.g. anyhow vs snafu, or Tokio Vs Smol. Once your project gets to a certain size you end up including every vaguely popular error handling crate. I think that's one of the big downsides of a small standard library which I haven't heard anyone mention.
I rather have a wonky standard library that works everywhere the full implementation is available, than this jigsaw mess, that isn't guaranteed to work everywhere.
Is also why alongside rich standard libraries, I am also quite fond of frameworks and middleware over plain libraries.
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.
I once read an interview with Guido van Rossum where he was asked what the point in time was when he realized that Python took off. He said, never, it just slowly but continuously grew.
This stuck with me. I hope we can say the same thing about Rust 10, 20 or 30 years from now.
I’m glad not completely off with my bet 5 years ago that Rust will get larger chunk of the market.
With the spread of AI Rust feels like a good candidate among Typescript and Python giants in a an era of coding assistant tools that needs a good nudge like Rust compiler.
As a counterpoint, Rust is one of the languages that AI is worst at writing - currently, at least.
Perhaps there could be a future where the compiler/checker will be able to integrate more closely with whichever agent is attempting to write Rust - more closely than the current paradigm, where a hapless Claude repeatedly bashes its head into the borrow checker to no avail.
I think I disagree with this sentiment. I’ve found AI to be poor at one-shotting rust but give it a short agentic loop running `cargo check` and it can often produce code more solid than that created with a dynamically typed language.
> Rust is one of the languages that AI is worst at writing - currently, at least
Everyone makes similar statements about AI, Ai is currently bad at this or that. I find it quite good to write Rust. Can you give a concrete example of what AI failed to write for you
Not OP but it consistently says that logging JSON (specifically nested JSON while not having escaped strings) with the tracing crate is not possible or provides wrong solutions.
However this is doable, just under an experimental feature flag since 2022[1]. I created this repo[2] with a small blog post, hopefully the scrapers can pick it up :')
The most interesting slide IMO:
Regarding Go, does Google actually "dominates“? Google has a team for the development of the language but does that mean it dominates?
Yes. To land a change in the Go standard library, you'll need 2 Google employees to approve your change on their "trusted devices".
This is demonstrably false. There are many approvers that do not work for Google.
Have you actually contributed to the Go standard library?
Yes, there are people who don't work for Google and can +2 on changes, but you still need 2 Google employees to at least +1 on your change before it can be submitted. This is mentioned in the Contribution Guide [0] and is enforced by Gerrit.
> Finally, to be submitted, a change must have the involvement of two Google employees, either as the uploader of the change or as a reviewer voting at least Code-Review +1. This requirement is for compliance and supply chain security reasons.
[0] https://go.dev/doc/contribute
When someone says demonstrably, I expect they would follow up with said demonstration
Then it should be easy to find examples of changes going into the STL that have not had the approval of multiple Googlers.
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!
To be clear: Rust does not have linear types. Rust has affine types. An affine Goose can't destroyed more than once. However zero isn't more than one. A linear Goose must be destroyed exactly once. Austral would be an example of a language with linear types.
In C++ if we destroy this Goose twice, probably everything catches on fire, whoops.
In Rust or Austral if we attempt to destroy this Goose twice the code doesn't compile. No executable for you until you stop destroying the Goose twice.
In C++ or Rust if we forget to destroy the Goose, the Goose-destroying code never runs. Hope that wasn't important.
In Austral if we forget to destroy the Goose, the code doesn't compile. No executable for you until you ensure the Goose is destroyed.
Rust has a combo: people come for safety, stay for usability.
Languages struggle to win on usability alone, because outside of passion projects it's really hard to justify a rewrite of working software to get the same product, only with neater code.
But if the software also has a significant risk of being exploited, or is chronically unstable, or it's slow and making it multi-core risks making it unstable, then Rust has a stronger selling point. Management won't sign off a rewrite because sum types are so cool, but may sign off an investment into making their product faster and safer.
Generally speaking I was more prone to agreeing with Rust-haters, and thought the whole idea of how Rust lifetimes are implemented is flawed, and the borrow checker is needlessly restrictive. I also disagree with some other ideas like the overreliance on generics to do static dispatch leading to large executables and slow compiles.
To be clear I still think these criticisms are valid. However after using the language in production, I've come to realize these problems in practice are manageable. The langauge is nice, decently well supported, has a relatively rich ecosystem.
Every programming language/ecosystem is flawed in some way, and I think as an experienced dev you learn to deal with this.
It having an actual functioning npm-like package management and build system makes making multiplatform software trivial. Which is something about C++ that kills my desire to deal with that language on a voluntary basis.
The ecosystem is full of people who try to do their best and produce efficient code, and try to understand the underlying problem and the machine. It feels like it still has a culture of technical excellence, while most libraries seem to be also well organized and documented.
This is in contrast to JS people, who often try to throw together something as fast as possible, and then market the shit out of it to win internet points, or Java/C# people who overcomplicate and obfuscate code by sticking to these weird OOP design pattern principles where every solution needs to be smeared across 5 classes and design patterns.
[dead]
Not sure if I would follow that point about usability. For me usability means also how usable it is to new people. How usable is the language to a foreign person compared to e.g. Python, Go or even Java - or if you want to mention functional languages like F#?
But besides that I am totally on your side, usability is great.
Couldn't agree more about the syntax. It may be "ugly" but it's just so much easier to mentally parse than ML-style syntax.
Here's an amusing anti-Rust talk: "Rust a language without poetry".[1] It's a reasonable critique, but the presentation is awful. It seems that someone took a paper and ran it through some AI program that provided text to speech and irrelevant images. Need to run it through a tool to extract the text, then discard the video.
"Every (lost) week spent refactoring to satisfy lifetime constraints..." Not wrong.
[1] https://www.youtube.com/watch?v=kLXXZddWCJU
That was amusing. It felt like those AI ads that YouTube sometimes feeds me, where a perpetual preamble promises to have a point and to get to it, which might have something to do with toe fungus or restoring virility but you’ll never know because the actual point is to lull you into a trance-like state of perfect thoughtlessness.
> "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.
> No, many are truly abandoned.
I've complained about that in the 3D graphics area. But that's niche. Recently I had to write some webcrap, a web server responder that runs under Apache mod_fcgid. I expected that area to Just Work. Works fine in Go, out of the box. There were about a half-dozen abandoned crates which sort of implemented that kind of server. I had to write one from scratch.[1]
The Rust compiler is great, but the crates... There are now enough of them to need curation. Some need to be moved to some obsolete status. Some need to make it to 1.0. Crates.io is starting to clog up with junk.
[1] https://github.com/John-Nagle/maptools/blob/main/server/src/...
I believe https://lib.rs/ aims to present information to find better crates.
I don't mind sorting by downloads or recent updates, so not all is loat, but I wish the status pages (are we X) and guides kept up.
Do you have examples
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 see it too often e.g., in Clojure, where lib authors even have to add "maintenance disclaimers"
I think this is a peculiarity of Clojure. Clojure is optimized for simplicity and as the saying goes: "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove."
I don't use Clojure these days. Maybe I should revisit the language. It has some really nice ideas.
There is nothing like "done" here. Somebody has to update dependencies at least - for security reasons.
Two words: "depend a bot"... Okay, three words... Anyway, updating dependencies and fixing bugs is "maintenance", not "adding new features". From the project management perspective, the project is in "done" state, if it doesn't require new features.
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.
> openssl
A library famous for collecting cruft that's irrelevant to actual use.
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 can agree to an extent that API designers sometimes (often?) over engineer for imagined problems.
At the same time, I've been working on an embedded Rust project and trying Embassy for the first time and it is _amazing_.
First of all I've had good logging and debug support with probe-rs. Secondly, being able to do ergonomic DMA transfers with async/await syntax feels like cheating. The core goes to sleep until your transfer finishes and an interrupt fires which wakes up the core and continues your async state machine, which the compiler built for you from your async code.
Distinct tasks can be split up into separate async functions, the type system models ownership of singleton hardware well (you can't use Pin 8 for your SPI bus there, you already "moved" it to your I2S peripheral over there!), and it all comes together with pretty minimal RAM usage, efficient use of the hardware, and low power consumption if you're mostly waiting on data transfers.
I'd be happy to talk more about practical problems if you want to get specific.
Good observations! I think Embassy worked out because its creator built it with the goal of shipping smart door locks, so the components of it he uses for that workflow work well.
I think ownership sometimes works for the reason bring up: Catching errors. I suspect you will find cases where you are not as pleased you can't use something you moved elsewhere! In some cases the ownership semantics map smoothly to control over hardware; in others, it's not so good of a fit. I also suspect you are overestimating how difficult DMA and power management are without async. (In rust or otherwise) What you described is a ubiquitous embedded workflow, minus the state machine.
Yep, I can definitely imagine cases where ownership can get in the way of doing something esoteric, but at least there are escape hatches for that if needed.
> I also suspect you are overestimating how difficult DMA and power management are without async.
I probably am, but having ergonomic syntax to orchestrate it all feels like something I wouldn't want to give up, after experiencing it.
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.
I'm not sure how a programming language can win other than having a thriving ecosystem and seeing use, as you point out. The current USA government removed the “Back to the Building Blocks: A Path Toward Secure and Measurable Software.” report and fired the people responsible though. So for all we know the current White House might be betting on PHP.
As professional developers, however, I think there is also the job market to consider. It obviously depends on where you live in the world, but in my area there have been 0 Rust jobs for 5 years. There are plenty of C++ jobs, there are even a few Zig jobs once in a while. Go on the other hand has seen an explosive growth, though probably as a replacement for C# and Java rather than for C++.
> The current USA government removed
Current USA government is on a defunding spree.
The threat hasn't disappeared they are just treating it as too expensive to worry about.
I'm not from US. Where I live I've seen more Rust jobs 1 than Go jobs 0.
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 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.
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.
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)
> 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.
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?
> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
The problem with retained mode GUIs is that, while the widget tree is, well, a a nice hierarchical tree, the widgets and the data model often need mutable references to each other, and it's these cross-references that break the tree-based ownership model of Rust.
> Things that live forever can be immutably borrowed, no problem
And mutably too, honestly, if that's what you need: https://doc.rust-lang.org/std/boxed/struct.Box.html#method.l...
> 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.
This corresponds to a C++ feature that has been added in C++11 (and other languages have this too AFAIK); good for libraries but but this has a runtime performance cost.
Since C++20 you can use constinit, or std::construct_at to avoid static initialization woes entirely
> 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.
True about C, and also true of most userspace applications.
However, the whole point of intrusive list (and other intrusive structures) is to flip the ownership relationship - the object owns the node, instead of the node owning the object. In other words, the intrusive list is a non-owning view over its elements. More importantly, they allow the same object to be present in multiple lists at once (as long as you add enough node hooks).
For example, you can have a pool-allocated Thread object that is simultaneously part of a queue of inactive threads of priority N, and also part of a wait queue for something else.
> A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
Right, I conflated it with the other examples, my bad; there it's because of shared mutable state, children elements needing to update their parents, and lack of inheritance in Rust
> Since C++20 you can use constinit, or std::construct_at to avoid static initialization woes entirely
This is just yet another bad defaults situation. Yes, that's the correct behaviour and so it's what Rust's statics do, but it wasn't how C++ worked so they had to add this constinit keyword. LazyStatic is solving the other thing - where we don't need runtime parameters but we are doing work at runtime so we aren't truly constant.
I think people are still working out the best way to do GUIs and game engines in Rust, but I wouldn't say that's because it's impossible. It's just quite new.
It took decades to get a C++ GUI framework that was really nice (Qt) and even then it used MOC so wasn't pure C++.
Intrusive lists are quite niche and not a big deal.
I think people are working on improving the ergonomics for Rc<Refcell< etc.
So there are definitely some downsides, but also so many upsides. You could easily say C++ can't replace Rust in many areas because of X, Y, Z.
> From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees)
Yeah, non-hierarchical references don't really lend themselves to static safety enforcement, so the question is what kind of run-time support the language has for non-hierarchical references. But here Rust has a disadvantage in that its moves are (necessarily) trivial and destructive.
For example, the scpptool-enforced memory-safe subset of C++ has non-owning smart pointers that safely support non-hierarchical (and even cyclical) referencing.
They work by wrapping the target object's type in a transparent wrapper that adds a destructor that informs any targeting smart pointers that the object is about to become invalid (or, optionally, any other action that can ensure memory safety). (You can avoid needing to wrap the target object's type by using a "proxy" object.)
Since they're non-owning, these smart pointers don't impose any restrictions on when/where/how they, or their target objects, are allocated, and can be used more-or-less as drop-in replacements for raw pointers.
Unfortunately, this technique can't be duplicated in Rust. One reason being that in Rust, if an object is moved, its original memory location becomes invalid without any destructor/drop function being called. So there's no opportunity to inform any targeting (smart) pointers of the invalidation. So, as you noted, the options in Rust are less optimal. (Not just "ergonomically", but in terms of performance, memory efficiency, and/or correctness checking.) And they're intrusive. They require that the target objects be allocated in certain ways.
Rust's policy of moves being (necessarily) trivial and destructive has some advantages, but it is not required (or arguably even helpful) for achieving "minimal-overhead" memory safety. And it comes with this significant cost in terms of non-hierarchical references.
So it seems to me that, at least in theory, an enforced memory-safe subset of C++, that does not add any requirements regarding moves being trivial or destructive, would be a more natural progression from traditional C++.
> Yeah, non-hierarchical references don't really lend themselves to static safety enforcement, so the question is what kind of run-time support the language has for non-hierarchical references.
Yes. Back references are a big problem.
I just wrote a bidirectional transitive closure algorithm that uses many back references, with heavy use of Rc, RefCell, Weak, and ".borrow()". It's 100% safe rust. This is the "proper" Rust way to write this sort of thing. The nice thing about doing it the "right" way was that, once it compiled, it needed few changes to work correctly. No mysterious errors at all. But it took a lot of work to get it to compile. Some sections had to be rewritten to get the ownership plumbing right.
I put it up on the Rust forums for comments, and got replies that I should stop doing all that fancy stuff and just use indices into arrays.[1] Or arena allocation. Things that bypass the Rust ownership system. Those approaches would probably have more bugs.
(I'm starting to see a way to do compile time checking for this sort of thing. The basic concept is that run time borrows must be disjoint as to type, disjoint as to scope, or disjoint as to instance. The first is easy. The second requires inspecting the call chain, and there are problems with templates due to ambiguity over what a type parameter does in .borrow() activity. The third is almost a theorem proving problem, but if you restrict compile time checks for disjoint instances to a single function (or maybe a "class", a struct and its functions), it might be manageable. All this might take too much cleverness to use in practice. Too much time getting the ownership plumbing right, even with compiler support. But I should write this up.)
[1] https://users.rust-lang.org/t/bidrectional-transitive-closur...
> I put it up on the Rust forums for comments, and got replies that I should stop doing all that fancy stuff and just use indices into arrays.[1] Or arena allocation. Things that bypass the Rust ownership system. Those approaches would probably have more bugs.
I ran into this years ago as well. It was very unsatisfying. Maybe Rust is just missing a good GC type?
It's not an allocation problem. It's a back-reference problem. When struct A owns struct B, and B needs to be able to find A, that's surprisingly difficult to set up in Rust. Even for structures where B is inside of A's struct.
k8s was originally java, iirc
It was, then a couple of early Go advocates joined the team, and ....
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 like modern Java and agree it's a much better language than Go and an excellent platform in general. But Java will not beat Go where small and fast native executables are required. The native story for Java will remain a sad one, builds being hyper slow (aot) or resulting in huge binaries (jlink).
Beyond a certain project size, GraalVM compiles to the same binary size as Go. Many k8s projects produce binary sizes of >100MB. I think this is because LOC in Go scales poorly.
Go's real edge over Java is in memory consumption, not in performance or binary size. Yet, this is also mostly true at the small-scale level. The edge again disappears for large projects needing large heaps.
If one needs a small and fast executable, then Rust should be used, not Go. I know a company that wished they would use Rust, not Go, for their services as poor Go performance and GC spikes made it a big headache.
Small and fast native executables sounds more like a niche than a real market. Don't get me wrong: really nice to have, but a raison d'etre?
You mean like those 300MB that need to be compressed with upx for distribution, like some Go projects?
Then you've not tried to do any cloud-native development. Go in cloud is like Python in AI
I have, and Go over here is only relevant as the language Docker and Kubernetes are written on.
Everything we do is written in JVM or CLR languages, JS/TS, and the occasional C++ for native libraries.
You must be joking. Over 75% of software on CNCF is written in Go; these include tools ranging from CI/CD to metrics and monitoring. It may not be popular to write your enterprise applications but it is certainly very popular in cloud infrastructure
Quite serious, CNCF products are basically Docker and Kubernetes related, that isn't what actual companies care about when moving their compute workloads from in-house into AWS, Azure, GCP, Vercel, Nelify, while paying big boys money to consulting agencies.
Many of those products are startups looking for attention in podcasts interviews and the like, and barely part of any enterprise cloud projects.
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.
I feel like Rust hasn't won yet - it needs to transition from the cool technology people because of the hype, novelty and the clout it affords them to the pragmatic boring technology people use because it's the best tool for the job.
In this stage, the unique standout features are given a lot of limelight, and people are a bit more forgiving with usability failings and library shortcomings, as that can be fixed later.
If they fail, they'll be relegated to the 'perpetually misunderstood' pile, like Haskell has.
Node/Ts has made the transition a while ago, Go's ride was a bit more bumpy (most ppl agree the language is good, but channels are a bit of an acquired taste).
I think Rust is in the process of making the jump. I think language devs and library maintainers are a bit more responsive to the borrow checker usability gripes (rather than the knee-jerk 'you just don't get it' reaction) and the ecosystem expands in both depth and breadth. Imo the question of Rust making it is more of a 'when' than 'if', but it's not there yet.
Also there is a certain npm feeling, every time I try out some trendy project, endless list of crates being compiled, even more interesting is seeing some being compiled multiple times.
I agree it is a problem. Though in my experience it's still not as bad as NPM. I still know what most of the dependencies do, even when there are hundreds. And you usually get hundreds of dependencies only for things that simply do a lot. E.g. one of my projects has hundreds of dependencies but that's because it includes wasmtime, which feels fairly justified.
In NPM you often get thousands of dependencies for things that should be simple like Vue.
Another factor is that projects are often split into many crates for compile time & modularity reasons, e.g. Gix is dozens of crates.
The "two versions of a crate" is actually a great thing. In other ecosystems like Python you would be simply unable to build the project at all because you can only have one version of any dependency.
The one thing that I think is a big problem is where you have splits in the ecosystem, e.g. anyhow vs snafu, or Tokio Vs Smol. Once your project gets to a certain size you end up including every vaguely popular error handling crate. I think that's one of the big downsides of a small standard library which I haven't heard anyone mention.
I mention that problem all the time.
I rather have a wonky standard library that works everywhere the full implementation is available, than this jigsaw mess, that isn't guaranteed to work everywhere.
Is also why alongside rich standard libraries, I am also quite fond of frameworks and middleware over plain libraries.
I feel the same way: https://news.ycombinator.com/item?id=43943178
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 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.
I once read an interview with Guido van Rossum where he was asked what the point in time was when he realized that Python took off. He said, never, it just slowly but continuously grew.
This stuck with me. I hope we can say the same thing about Rust 10, 20 or 30 years from now.
I dunno I would say maybe the point at which Microsoft and Google started using it.
I’m glad not completely off with my bet 5 years ago that Rust will get larger chunk of the market. With the spread of AI Rust feels like a good candidate among Typescript and Python giants in a an era of coding assistant tools that needs a good nudge like Rust compiler.
As a counterpoint, Rust is one of the languages that AI is worst at writing - currently, at least.
Perhaps there could be a future where the compiler/checker will be able to integrate more closely with whichever agent is attempting to write Rust - more closely than the current paradigm, where a hapless Claude repeatedly bashes its head into the borrow checker to no avail.
I think I disagree with this sentiment. I’ve found AI to be poor at one-shotting rust but give it a short agentic loop running `cargo check` and it can often produce code more solid than that created with a dynamically typed language.
> Rust is one of the languages that AI is worst at writing - currently, at least
Everyone makes similar statements about AI, Ai is currently bad at this or that. I find it quite good to write Rust. Can you give a concrete example of what AI failed to write for you
Not OP but it consistently says that logging JSON (specifically nested JSON while not having escaped strings) with the tracing crate is not possible or provides wrong solutions.
However this is doable, just under an experimental feature flag since 2022[1]. I created this repo[2] with a small blog post, hopefully the scrapers can pick it up :')
[1]https://github.com/tokio-rs/tracing/discussions/1906
[2]https://github.com/joswayski/tracing-valuable-example
I was wondering where I recognized your name before, before I realized you're the linebender guy.
Hello! Big fan of your UI research
also the creator of the font Inconsolata
and of Even Toned Screens, the halftoning algorithm used by many linux print drivers.
Slides from video description
https://docs.google.com/presentation/d/1SoDsm_m_pb_gS6Y98Hgh...
Thanks! We've put that in the thread header.
Yes, thanks. There's an hour of talking head but only about 15 slides.