Regarding Go, does Google actually "dominates“? Google has a team for the development of the language but does that mean it dominates?

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.

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.

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 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.

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.

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'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.

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.

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

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 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.

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.

Python was my first language and that is precisely how it felt. I would be at a convention or conference and mention python and it seemed like people didn't care, had a negative opinion or just didn't use it. It was treated as something only semi-programmers did, like people whose job wasn't actually programming, business analysts or scientists.

Then one day python was suddenly top of the charts, probably post python 3 (old timers hated it but it really improved ergonomics) but not immediately so. Rather later on when they fixed the performance loss from 2->3 (which looking back as a primarily Rust coder now, was a hilarious argument that community had internally because even my worst, most quickly cobbled together rust code beats some of my best python code at the same task performance wise).

I dunno I would say maybe the point at which Microsoft and Google started using it.

Thanks! We've put that in the thread header.

also the creator of the font Inconsolata