5 ms·

The limits of Rust, or why you should probably not follow Amazon and Cloudflare

90 points by randomint64 5mo ago

Aurornis 5mo ago
Lots of tortured logic in this post. 1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. 2. Rust ranks lower on the most used languages list because it's newer than Java, Python, C, and all of the others higher on the list. 3. You don't need to use async Rust. If you do, I disagree that it's as hard as this is implying, but I would agree that it's not as easy as writing sync code. 4. Rust projects don't decay like this is saying. Rust has editions and you can stay on an older edition until you're ready to port it forward. My experience with jumping to a new Rust edition has been easy across all projects so far. It's funny that they argue that adding new features to the language leads to unmanageable complexity, because the very next topic argues that the standard library doesn't have enough features. 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. Most of the blog is an ad for the author's book. I was hoping this post had some substance but I think they chose the title first to attract clicks for the book ad and then tried really hard to find some content for the article second.
- traderj0e 5mo ago
  For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads. Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a big motivator for Go and Kotlin coroutines, and why Rust and Python put so much effort into adding event loops after the fact.
  - jen20 5mo ago
    > why Rust and Python put so much effort into adding event loops after the fact. Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.
    - traderj0e 5mo ago
      Er yeah technically the event loop isn't part of Rust, just the async/await syntax. But it's implied that you're going to use some event loop with it.
      - tracker1 5mo ago
        No, it's implied that you're going to use some sort of async runtime with it... said runtime can be simple real threads, a thread pool or virtual threads and there are implementations for all of them. And even then, it's super easy to start a new real thread in rust, around any async runtime.
        jen20 5mo ago
        While true, this isn’t what I’m talking about: Rust had _built in_ green threads at one point, the same as Go [1]. [1]: https://rust-lang.github.io/rfcs/0230-remove-runtime.html https://rust-lang.github.io/rfcs/0230-remove-runtime.html
      - jen20 5mo ago
        True now, but there was a time when async/await was _not_ part of Rust, and a runtime was.
  - tracker1 5mo ago
    For that matter, even if you do use async, if you're writing a service based app (such as web services), IMO, you'd probably just want to center on tokio and axum, then stick to the tokio ecosystem. The main reason it's not a blessed standard library thing, is that Rust can scale down into embedded systems usage, and you aren't going to use something like Tokio there... that doesn't mean you shouldn't just use what everyone else does at a higher level application. Also, in regards to OP's reference to changes to Rust, it's not changes/additions or bug fixes that should be a concern, it's the number of breaking changes. For a contemporary counter example, look at how much C# has changed since the .Net Core fork started out... They're on version 11 now (skipped v4), and that doesn't count the library sub-version shifts along the way. And a lot of critical banking infrastructure is written in and running on it (as well as Java). Your money is literally relying on it.
    - SkiFire13 5mo ago
      > And a lot of critical banking infrastructure is written in and running on it How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?
      - moomin 5mo ago
        IME: less than you’d think. I know one major C# project that’s only half completed its migration and that huge (both in terms of what’s been achieved and what still needs doing). There’s another that keeps it for the front end because it runs on >10,000 client machines. All the others, big or small, have migrated with small carve-outs for stuff .NET Core doesn’t and probably never will support.
      - tracker1 5mo ago
        From recent experience I'd put it slightly higher on the old framework, but plenty of new dev on v5+ and I think sticking on framework is worse at this point. Though I would say that breaking changes since Core 3 have been pretty limited. V5 unified .net under the new core as the path forward for framework users as well.
  - ViewTrick1002 5mo ago
    Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead. History: This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading. https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
    - sysguest 5mo ago
      well rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)
      - ViewTrick1002 5mo ago
        Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored. For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages. Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now. [1]: https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
        deleted 5mo ago
        [deleted]
  - andriy_koval 5mo ago
    > Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code I think majority Java code is just sequential blocking code, and it works just fine.
  - fulafel 5mo ago
    This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago. (eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)
    - traderj0e 5mo ago
      I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.
      - deleted 5mo ago
        [deleted]
      - fulafel 5mo ago
        I can believe some people have implemented misconfigured thread pools, being worse off than with no thread pool at all. But this not an argument that justifies a "multitasking isn't a real choice for backends" position. (Then there's bugs that happen in both asyncio and threaded programs, that stem from various queuing problems in the system, manifesting as work getting backed up in the concurrency layer. You end up needing backpressure in both worlds, thread pool limits are the wrong layer to do it.)
- pointlessone 5mo ago
  > 3. You don't need to use async Rust. Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.
  - andriy_koval 5mo ago
    > Want to build a web app, every more or less popular framework is async. I think its the same as Java, Tomcat has some async threadpool inside, they just hide it from you, and your favorite rust framework doesn't, you need manually move your sync logic to Tokio spawn_blocking
    - traderj0e 5mo ago
      Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI https://www.youtube.com/watch?v=lJ3NC-R3gSI All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S
  - bryanlarsen 5mo ago
    And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking. You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.
    - simon_void 5mo ago
- tialaramex 5mo ago
  > You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust. (Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application. If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.
- nextaccountic 5mo ago
  > 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices
- lenkite 5mo ago
  > 3. You don't need to use async Rust. This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.
  - worik 5mo ago
    I do a lot of real-time audio programming in Rust because it is so expressive and the compiler so helpful But I disagree. I do not use asyc/await for my asynchronous programming in Rust if I get the choice. I have used it extensively in other languages, and when I've had to in Rust, but there are many problems The paradigm itself is not suited to hard real-time programming. An explicit event loop is unbeatable in that case The model does not fit properly in the Rust memory model, and quite often you find yourself using pretzel logic and "magic incantations" to get around that It is synchronous in style, and a footgun as CPU bound operations can block it. The threading support in Rust is superb and for the vast majority of cases a perfect fit Async/await in Rust is a very impressive technical achievement, I am very impressed by how much gets done so efficiently and how well the runtime perform
irishcoffee 5mo ago
This gets so old. Rust is a programming language. It does some things really well, some things less so. It isn't a panacea, it's a tool. People can use it because they like it, right-tool-for-the-job or not. People can hate it, hating a programming language is one of the most benign things to hate in the whole world. "Language-ist" is a world I never want to live in. Feels like there are some people who love rust, and some people who hate rust, and most everyone else doesn't give a shit. Everyone is right and everyone is wrong, depending on who you ask. Can't we just go back to the emacs vs vi debate? Is that the itch people are trying to scratch?
- mwigdahl 5mo ago
  vi would be much easier to rewrite in Rust.
  - NoboruWataya 5mo ago
    Helix is in fact written in Rust and is now a frequent contender in the editor wars.
- traderj0e 5mo ago
  The post doesn't hate on Rust, it's more saying you probably shouldn't use it for high-level code like a web backend. Which is pretty reasonable.
  - vablings 5mo ago
    I have been churning away writing a custom backed in rust using Dioxus, it is excellent for this kind of high level work.
  - tracker1 5mo ago
    Having written web backends for three decades in quite a few languages along the way, I disagree. You can definitely write some relatively simple backends in Rust. Tokio and Axum make it quite friendly, and depending on what you are connecting to it becomes super easy, barely and inconvenience. Even if you cheat and do a lot of cloning across library boundaries, it's still likely to perform pretty well compared to a lot of prevailing frameworks. I'd say I'm most recently most familiar with C# and FastEndpoints as well as TS/JS and Hono, but I've used many others. I've also done a bit with Rust and Tokio/Axum and it's not been significantly worse than the former mentioned options. That said, the runtime containers are a fraction of the size, start significantly faster, and use a lot less memory with Rust. And once your boilerplate is in place (jwt/oauth, db context, etc), it's roughly the same work.
cbsmith 5mo ago
This is a bizarre article, and it kind of reminds me of the concept that the only truly good software is the software you've never used.
egorelik 5mo ago
A common thread I see in this, and other articles of its kind, is that rarely do they come out and say what kind of project they are working on, leaving the headline to sound generically applicable. I can make some guesses, given the emphasis on async, that they contrast with Go, and the mention of systems programming as an exception. But after enough of these, one would get the impression that Rust is primarily a backend language, competing with other backend languages, that happens to also be good for systems. I'm not sure that is even the use case driving corporate adoption.
- traderj0e 5mo ago
  The article should've been clear about use cases. I think the reason for the focus on backends is because that's where people keep randomly wanting to rewrite in Rust.
- tialaramex 5mo ago
  The big driver for corporate adoption is that this is probably a Silver Bullet in the sense meant in "No Silver Bullet". An order of magnitude improvement for software engineering. I think the sort of person who figures they don't need to read the book because the title told them there was a Murder on the Orient Express believes Brooks says that it's just all irreducible complexity, too bad, stop looking. In fact "No Silver Bullet" says nothing of the sort and we would be astonished if, after so much time, literally none were discovered. There are plenty of domains where Rust makes sense if you could just choose Rust, but probably doesn't make enough sense that you should retrain or even re-hire a whole team. Google spends money training devs who don't know Rust, because it's getting enough value out that it makes sense to do that, your web slinging business running on razor thin margins is probably fine in PHP or whatever and should not buy Rust training.
- ameliaquining 5mo ago
  In fairness, the post specifically mentions Amazon and Cloudflare, which are using Rust largely for backend stuff (though also for lower-level systems-y stuff, and I think Go is also a favored backend language at Cloudflare). But yes, other large tech companies (Google and Meta come to mind) are using Rust primarily for the lower-level systems-y stuff, where Go isn't an option and the alternative to Rust is C++. These applications are also less likely to need async and so don't have to deal with that set of rough edges.
unethical_ban 5mo ago
I don't have a problem with this post, in fact I think it fully redeems any criticism by describing the stronger use cases for the language. Takeaways: If picking an arbitrary language to learn, if you are building small-to-medium scale things that require async, rust is not the first thing to reach for. The stdlib and the package ecosystem is a mess. --- Use if: If you need gigascale performance and have the resources to learn it and deal with the complexity of async. If you are writing performant global OS libraries. If you are writing IoT and want something with more protection than C.
traderj0e 5mo ago
Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.
- nothinkjustai 5mo ago
  No it’s not bad at all. If you’re creating a library you might run into some hard problems, but for application code it’s pretty easy.
- steveklabnik 5mo ago
  Rust’s async makes some design decisions that make it a unique feature: no other language has zero allocations to do async, for example. (In C++’s version you can get it to do no allocations if you do certain things, like making the required allocator a no-op, in my understanding, but it conceptually requires a call to an allocator) This makes it suitable for a much wider variety of tasks than other languages with similar features, but does mean that there are more details that you need to care about than in other languages that are higher level. This means it is controversial: some people would prefer a higher level experience, but for those who do use it for its full range of tasks, it’s great. There are some rough edges, but it’s just a feature that, even outside of Rust, some people just fundamentally dislike. So it draws a lot of heat from all sides. It is also probably the single largest driver of adoption of the language. Rust started truly taking off once it landed.
  - traderj0e 5mo ago
    "it’s just a feature that, even outside of Rust, some people just fundamentally dislike" is why I have a hard time gauging this. I know Python users whine about it endlessly just because it's a feature from JS, even though Python's existing concurrency features were the worst of both worlds. The Rust-specific async sounds interesting. I should give it a try.
  - tracker1 5mo ago
    I can only speak for myself, but I kind of refused to get started with Rust until async landed... only because it's kind of a core of scalable services. I think it's pretty great in that you can use an async runtime, but still launce native threads if you want/need to for specific scenarios. It's pretty great and for most high level tasks, I wouldn't classify it as significantly more difficult than C#. A few other things I've done with it have been written by AI as much as myself... which has similarly been pretty nice... Rust code can be very easy to reason with (lifetime syntax not withstanding). For some reason Rust lifetimes burn my soul.
gamander2 5mo ago
[dead]
- fluffybucktsnek 5mo ago
  Why don't you just compile rustc?
- _davide_ 5mo ago
  Lol, use Gentoo
ben-schaaf 5mo ago
> Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog. > During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases. Some corrections: Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break backwards compatibility. Python saw 5 major releases, each breaking backwards compatibility. Counting all releases they had 132. Node has an LTS every year. There were 6 LTS versions in the last 6 years. Those releases also included major breaking changes. Go had no new major version, like rust it's only made minor changes. So going by the author's own evaluation, rust and go are considerably better for project decay. > For example, I just looked at the dependencies of a small project I'm working on, and we have 5+ (!) different crypto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto ring is explicitly an experiment, not suitable for use. My guess is the author looked at their Cargo.lock to determine what duplicated dependencies they have. For the uninitiated, rust libraries can have optional dependencies that only get included under certain conditions. A common pattern is for a library to support multiple underlying implementations, such as different crypto libraries. For instance rustls has both ring and aws-lc-rs as optional dependencies, meaning that both get included in the Cargo.lock file when resolving dependencies. That doesn't mean that both are actually being used.
- aabhay 5mo ago
  Ring is a de facto standard for better or worse. In our codebase we basically have no choice but to use it
  - mkj 5mo ago
    The rustcrypto crates seem a lot better maintained and will probably supplant ring in future. Ring maintenance seems hostile to use outside of expected use cases.
- IshKebab 5mo ago
  Yeah on top of that I've seen virtually no evidence that Rust projects really decay. I bet you can compile some really old Rust projects with the latest Rust with no problems. In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is: 1. Go. Very reliable. 2. Rust. Also very reliable. 3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently. 4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently). 5. JavaScript. Good fucking luck.
nothinkjustai 5mo ago
Weird post. One could pick any language OP recommends over Rust and find just as many if not more reasons not to use it.
pornel 5mo ago
It's a rehash of a bunch of old misconceptions. I thought we've buried these when people got actual experience with Rust. The dumbest one is counting changelog lines. Have you even read them? These days most of them are "obscure libstd function is now allowed in const contexts". The regular Rust releases include compiler improvements, libstd evolution, and build system tweaks. Nobody's saying C keeps changing because LLVM has a long changelog or CMake added a new feature.
- tialaramex 5mo ago
  I agree but more common than "Now allowed in const context" is "This new type/method/free function is now stabilized" e.g. in 1.95 they stabilized a bunch of "Atomic update" methods such as: AtomicPtr::update which is a nicer way to write one of those "Get the pointer, do some stuff to calculate a new value from the old one, then try to swap its old value for the new one, if the pointer changed meanwhile repeat each time with the changed value until we succeed" stanzas some low-level people will have written a hundred times. This library feature does all that boring boilerplate for you, you just write that "calculate a new value" code as a lambda (or function, Rust doesn't mind) and you're done. That's the sort of feature where if it didn't exist when you wrote your code, you go "That's nice" and move on, no change needed, but now that it does exist you might use it in future software you write. If you have a team writing Rust it probably makes sense to have somebody read these changelogs, but that's about it.
  - saghm 5mo ago
    I tend the be the one on my team who reads them. I don't think I've ever had a coworker in close to seven years of writing Rust professionally that had trouble because they didn't read them. At most, sometimes I'll suggest using some function I remembered reading about to someone in a code review, and then they'll go "oh, cool!", and use it, and then they don't need to do anything else. Meanwhile, the times that there are useful changes under the hood, you get them in a few weeks instead of maybe some time later in the year or next year. I don't understand at all how someone could plausibly argue that this is a problem in this context. At absolute most, you could argue against some of the downstream effects of the rapid release cycle (like how it reinforces the small standard library size; more surface area means potentially more bugs, and putting out an extra release to fix them when there are already releases so frequently is a hard sell, so it makes sense to keep things slim), but the article doesn't have anywhere close to that level of nuance in addressing the issue, so I'm skeptical that this is even something they've considered.
vld_chk 5mo ago
This is the case, when author argues about the right thing (you do not need Rust everywhere on every project and in every feature, especially if your team has 0 prior exposure to Rust or at least C++), but provide very awkward arguments which are not aligned with core thesis.
pjmlp 5mo ago
Yes, Rust should not be used for everything, like any other language shouldn't, but some devs only see nails. Example Amazon uses Rust mostly for actual systems programming, writing hypervisors and cloud infrastructure low level services. They have plenty of other stuff in there as well.
Panzerschrek 5mo ago
It's not mentioned, that the language itself is designed in such a way, so it requires a lot of boilerplate involving traits. The same results (both safety and speed) are achievable without using traits at all but by relying on duck-typing.
_davide_ 5mo ago
Except rust is way more productive than any other language out there...
- worik 5mo ago
  > ...rust is way more productive than any other language... Eventually The learning curve is unfun
joshka 5mo ago
Every single one of this authors articles that I've read (and it's a fair few), are poorly argued, and generally incorrect. It would be easy to engage and disprove, but it's better not to give this air. Just say no to kerkour.
throwa356262 5mo ago
"Rust's biggest weakness: an anemic standard library" As someone who programs in both go and rust, I could not agree more.
zesterer 5mo ago
This is largely FUD, written with the intent of sounding professional and with expertise, but in practice there are many tell-tale signs that the author doesn't really know what they're talking about. > the biggest drawback of async is the fragmentation of the ecosystem 95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it. > So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks. This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry. > Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems. No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.
- worik 5mo ago
  > 95% of the ecosystem uses tokio nowadays The other 5% matters a lot. > but pretty much all async libraries will work with tokio, "pretty much" is useful until it's not. When it's not it is a special type of hell
grougnax 5mo ago
Rust has no limits. You do have limits.
dev_l1x_be 5mo ago
I am not sure how many times RIIR helped me, my customers, teams to achieve better outcomes. Energy use matters. Memory safety matters. ML (Meta Language) features are a bliss to C/C++ languages. With the coding agents picking up Rust is much easier than it was 5 years ago. I am not sure what impact the lack of crypto primitives in the standard library even has. I can use hashing (even the more advanced ones like blake3) and some of the NACL primitives and that is fine. Async Rust is a bit hard, I agree. Function coloring is probably not the best, but I am not sure how to not have that in a compiled language like Rust, or how to improve it.
djmunro 5mo ago
[flagged]
NuSkooler 5mo ago
I've now worked with 3 teams that have moved from Python (2/3) and C++ (1/3) to (async) Rust. All successfully, all with less bugs, moving faster, etc. And now we have AI.

90 points by randomint64 5mo ago

Lots of tortured logic in this post. 1. You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. 2. Rust ranks lower on the most used languages list because it's newer than Java, Python, C, and all of the others higher on the list. 3. You don't need to use async Rust. If you do, I disagree that it's as hard as this is implying, but I would agree that it's not as easy as writing sync code. 4. Rust projects don't decay like this is saying. Rust has editions and you can stay on an older edition until you're ready to port it forward. My experience with jumping to a new Rust edition has been easy across all projects so far. It's funny that they argue that adding new features to the language leads to unmanageable complexity, because the very next topic argues that the standard library doesn't have enough features. 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. Most of the blog is an ad for the author's book. I was hoping this post had some substance but I think they chose the title first to attract clicks for the book ad and then tried really hard to find some content for the article second.

traderj0e 5mo ago
For the use cases the author is alluding to, you do need to use async. Non-cooperative threaded multitasking isn't a real choice for backends, and Rust doesn't have virtual threads. Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code, cause they didn't want to be doing blocking stuff with a thread pool. That was a big motivator for Go and Kotlin coroutines, and why Rust and Python put so much effort into adding event loops after the fact.
- jen20 5mo ago
  > why Rust and Python put so much effort into adding event loops after the fact. Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.
  - traderj0e 5mo ago
    Er yeah technically the event loop isn't part of Rust, just the async/await syntax. But it's implied that you're going to use some event loop with it.
    - tracker1 5mo ago
      No, it's implied that you're going to use some sort of async runtime with it... said runtime can be simple real threads, a thread pool or virtual threads and there are implementations for all of them. And even then, it's super easy to start a new real thread in rust, around any async runtime.
      - jen20 5mo ago
        While true, this isn’t what I’m talking about: Rust had _built in_ green threads at one point, the same as Go [1]. [1]: https://rust-lang.github.io/rfcs/0230-remove-runtime.html https://rust-lang.github.io/rfcs/0230-remove-runtime.html
    - jen20 5mo ago
      True now, but there was a time when async/await was _not_ part of Rust, and a runtime was.
- tracker1 5mo ago
  For that matter, even if you do use async, if you're writing a service based app (such as web services), IMO, you'd probably just want to center on tokio and axum, then stick to the tokio ecosystem. The main reason it's not a blessed standard library thing, is that Rust can scale down into embedded systems usage, and you aren't going to use something like Tokio there... that doesn't mean you shouldn't just use what everyone else does at a higher level application. Also, in regards to OP's reference to changes to Rust, it's not changes/additions or bug fixes that should be a concern, it's the number of breaking changes. For a contemporary counter example, look at how much C# has changed since the .Net Core fork started out... They're on version 11 now (skipped v4), and that doesn't count the library sub-version shifts along the way. And a lot of critical banking infrastructure is written in and running on it (as well as Java). Your money is literally relying on it.
  - SkiFire13 5mo ago
    > And a lot of critical banking infrastructure is written in and running on it How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?
    - moomin 5mo ago
      IME: less than you’d think. I know one major C# project that’s only half completed its migration and that huge (both in terms of what’s been achieved and what still needs doing). There’s another that keeps it for the front end because it runs on >10,000 client machines. All the others, big or small, have migrated with small carve-outs for stuff .NET Core doesn’t and probably never will support.
    - tracker1 5mo ago
      From recent experience I'd put it slightly higher on the old framework, but plenty of new dev on v5+ and I think sticking on framework is worse at this point. Though I would say that breaking changes since Core 3 have been pretty limited. V5 unified .net under the new core as the path forward for framework users as well.
- ViewTrick1002 5mo ago
  Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead. History: This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading. https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo...
  - sysguest 5mo ago
    well rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)
    - ViewTrick1002 5mo ago
      Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored. For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages. Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now. [1]: https://rfd.shared.oxide.computer/rfd/0609 https://rfd.shared.oxide.computer/rfd/0609
      - deleted 5mo ago
        [deleted]
- andriy_koval 5mo ago
  > Before Java got virtual threads in Project Loom, people were typically using some promises equivalent even though it mangled the heck out of all your code I think majority Java code is just sequential blocking code, and it works just fine.
- fulafel 5mo ago
  This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago. (eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)
  - traderj0e 5mo ago
    I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.
    - deleted 5mo ago
      [deleted]
    - fulafel 5mo ago
      I can believe some people have implemented misconfigured thread pools, being worse off than with no thread pool at all. But this not an argument that justifies a "multitasking isn't a real choice for backends" position. (Then there's bugs that happen in both asyncio and threaded programs, that stem from various queuing problems in the system, manifesting as work getting backed up in the concurrency layer. You end up needing backpressure in both worlds, thread pool limits are the wrong layer to do it.)
pointlessone 5mo ago
> 3. You don't need to use async Rust. Technically correct, but… Want to build a web app, every more or less popular framework is async. Want to make a web request? High change of async. Database? Very likely async, too. A huge fraction of crates are async. Right now crates.io says there are "54172 reverse dependencies of tokio”. And the page that lists them struggles mightily to load. And that’s only direct dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.
- andriy_koval 5mo ago
  > Want to build a web app, every more or less popular framework is async. I think its the same as Java, Tomcat has some async threadpool inside, they just hide it from you, and your favorite rust framework doesn't, you need manually move your sync logic to Tokio spawn_blocking
  - traderj0e 5mo ago
    Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI https://www.youtube.com/watch?v=lJ3NC-R3gSI All the "async" stuff is super poorly named. They mean cooperative multitasking, or I guess "async within a single kernel thread." Yeah multiple kernel threads are asynchronous but "async" doesn't mean that :S
- bryanlarsen 5mo ago
  And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking. You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.
  - simon_void 5mo ago
tialaramex 5mo ago
> You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust. Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust. (Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application. If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.
nextaccountic 5mo ago
> 5. If you want a batteries-included standard library I agree that you should pick Python or Go instead. But then you should be warned that, among the various http clients Python has in their stdlib, none should be used. Or the many datetime libs in the Python stdlib, they should not be used. LLMs know this by the way and will reach for actual best practices
lenkite 5mo ago
> 3. You don't need to use async Rust. This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.
- worik 5mo ago
  I do a lot of real-time audio programming in Rust because it is so expressive and the compiler so helpful But I disagree. I do not use asyc/await for my asynchronous programming in Rust if I get the choice. I have used it extensively in other languages, and when I've had to in Rust, but there are many problems The paradigm itself is not suited to hard real-time programming. An explicit event loop is unbeatable in that case The model does not fit properly in the Rust memory model, and quite often you find yourself using pretzel logic and "magic incantations" to get around that It is synchronous in style, and a footgun as CPU bound operations can block it. The threading support in Rust is superb and for the vast majority of cases a perfect fit Async/await in Rust is a very impressive technical achievement, I am very impressed by how much gets done so efficiently and how well the runtime perform

irishcoffee 5mo ago

This gets so old. Rust is a programming language. It does some things really well, some things less so. It isn't a panacea, it's a tool. People can use it because they like it, right-tool-for-the-job or not. People can hate it, hating a programming language is one of the most benign things to hate in the whole world. "Language-ist" is a world I never want to live in. Feels like there are some people who love rust, and some people who hate rust, and most everyone else doesn't give a shit. Everyone is right and everyone is wrong, depending on who you ask. Can't we just go back to the emacs vs vi debate? Is that the itch people are trying to scratch?

mwigdahl 5mo ago
vi would be much easier to rewrite in Rust.
- NoboruWataya 5mo ago
  Helix is in fact written in Rust and is now a frequent contender in the editor wars.
traderj0e 5mo ago
The post doesn't hate on Rust, it's more saying you probably shouldn't use it for high-level code like a web backend. Which is pretty reasonable.
- vablings 5mo ago
  I have been churning away writing a custom backed in rust using Dioxus, it is excellent for this kind of high level work.
- tracker1 5mo ago
  Having written web backends for three decades in quite a few languages along the way, I disagree. You can definitely write some relatively simple backends in Rust. Tokio and Axum make it quite friendly, and depending on what you are connecting to it becomes super easy, barely and inconvenience. Even if you cheat and do a lot of cloning across library boundaries, it's still likely to perform pretty well compared to a lot of prevailing frameworks. I'd say I'm most recently most familiar with C# and FastEndpoints as well as TS/JS and Hono, but I've used many others. I've also done a bit with Rust and Tokio/Axum and it's not been significantly worse than the former mentioned options. That said, the runtime containers are a fraction of the size, start significantly faster, and use a lot less memory with Rust. And once your boilerplate is in place (jwt/oauth, db context, etc), it's roughly the same work.

cbsmith 5mo ago

This is a bizarre article, and it kind of reminds me of the concept that the only truly good software is the software you've never used.

egorelik 5mo ago

A common thread I see in this, and other articles of its kind, is that rarely do they come out and say what kind of project they are working on, leaving the headline to sound generically applicable. I can make some guesses, given the emphasis on async, that they contrast with Go, and the mention of systems programming as an exception. But after enough of these, one would get the impression that Rust is primarily a backend language, competing with other backend languages, that happens to also be good for systems. I'm not sure that is even the use case driving corporate adoption.

traderj0e 5mo ago
The article should've been clear about use cases. I think the reason for the focus on backends is because that's where people keep randomly wanting to rewrite in Rust.
tialaramex 5mo ago
The big driver for corporate adoption is that this is probably a Silver Bullet in the sense meant in "No Silver Bullet". An order of magnitude improvement for software engineering. I think the sort of person who figures they don't need to read the book because the title told them there was a Murder on the Orient Express believes Brooks says that it's just all irreducible complexity, too bad, stop looking. In fact "No Silver Bullet" says nothing of the sort and we would be astonished if, after so much time, literally none were discovered. There are plenty of domains where Rust makes sense if you could just choose Rust, but probably doesn't make enough sense that you should retrain or even re-hire a whole team. Google spends money training devs who don't know Rust, because it's getting enough value out that it makes sense to do that, your web slinging business running on razor thin margins is probably fine in PHP or whatever and should not buy Rust training.
ameliaquining 5mo ago
In fairness, the post specifically mentions Amazon and Cloudflare, which are using Rust largely for backend stuff (though also for lower-level systems-y stuff, and I think Go is also a favored backend language at Cloudflare). But yes, other large tech companies (Google and Meta come to mind) are using Rust primarily for the lower-level systems-y stuff, where Go isn't an option and the alternative to Rust is C++. These applications are also less likely to need async and so don't have to deal with that set of rough edges.

unethical_ban 5mo ago

I don't have a problem with this post, in fact I think it fully redeems any criticism by describing the stronger use cases for the language. Takeaways: If picking an arbitrary language to learn, if you are building small-to-medium scale things that require async, rust is not the first thing to reach for. The stdlib and the package ecosystem is a mess. --- Use if: If you need gigascale performance and have the resources to learn it and deal with the complexity of async. If you are writing performant global OS libraries. If you are writing IoT and want something with more protection than C.

traderj0e 5mo ago

Is async in Rust really this bad? Last time I used Rust was before that existed. I know it's a pain in Python because they bolted it on way after, but in JS it's a breeze because everything standardized on promises early.

nothinkjustai 5mo ago
No it’s not bad at all. If you’re creating a library you might run into some hard problems, but for application code it’s pretty easy.
steveklabnik 5mo ago
Rust’s async makes some design decisions that make it a unique feature: no other language has zero allocations to do async, for example. (In C++’s version you can get it to do no allocations if you do certain things, like making the required allocator a no-op, in my understanding, but it conceptually requires a call to an allocator) This makes it suitable for a much wider variety of tasks than other languages with similar features, but does mean that there are more details that you need to care about than in other languages that are higher level. This means it is controversial: some people would prefer a higher level experience, but for those who do use it for its full range of tasks, it’s great. There are some rough edges, but it’s just a feature that, even outside of Rust, some people just fundamentally dislike. So it draws a lot of heat from all sides. It is also probably the single largest driver of adoption of the language. Rust started truly taking off once it landed.
- traderj0e 5mo ago
  "it’s just a feature that, even outside of Rust, some people just fundamentally dislike" is why I have a hard time gauging this. I know Python users whine about it endlessly just because it's a feature from JS, even though Python's existing concurrency features were the worst of both worlds. The Rust-specific async sounds interesting. I should give it a try.
- tracker1 5mo ago
  I can only speak for myself, but I kind of refused to get started with Rust until async landed... only because it's kind of a core of scalable services. I think it's pretty great in that you can use an async runtime, but still launce native threads if you want/need to for specific scenarios. It's pretty great and for most high level tasks, I wouldn't classify it as significantly more difficult than C#. A few other things I've done with it have been written by AI as much as myself... which has similarly been pretty nice... Rust code can be very easy to reason with (lifetime syntax not withstanding). For some reason Rust lifetimes burn my soul.

gamander2 5mo ago

[dead]

fluffybucktsnek 5mo ago
Why don't you just compile rustc?
_davide_ 5mo ago
Lol, use Gentoo

ben-schaaf 5mo ago

> Between January 2020 and May 2026 Rust has seen 54 releases, which amounts to 7500 lines of changelog. > During the same period, there was 12 Go releases, 12 Node.js releases (but only 2 LTS) and 5 Python releases. Some corrections: Rust saw 54 (I assume that's correct, I didn't recount) minor releases, with a few minor breaking changes. If we only count editions there were 2 releases, but again those don't break backwards compatibility. Python saw 5 major releases, each breaking backwards compatibility. Counting all releases they had 132. Node has an LTS every year. There were 6 LTS versions in the last 6 years. Those releases also included major breaking changes. Go had no new major version, like rust it's only made minor changes. So going by the author's own evaluation, rust and go are considerably better for project decay. > For example, I just looked at the dependencies of a small project I'm working on, and we have 5+ (!) different crypto libraries: 2 different versions of ring, aws-lc-rs, boring, and various libraries from RustCrypto ring is explicitly an experiment, not suitable for use. My guess is the author looked at their Cargo.lock to determine what duplicated dependencies they have. For the uninitiated, rust libraries can have optional dependencies that only get included under certain conditions. A common pattern is for a library to support multiple underlying implementations, such as different crypto libraries. For instance rustls has both ring and aws-lc-rs as optional dependencies, meaning that both get included in the Cargo.lock file when resolving dependencies. That doesn't mean that both are actually being used.

aabhay 5mo ago
Ring is a de facto standard for better or worse. In our codebase we basically have no choice but to use it
- mkj 5mo ago
  The rustcrypto crates seem a lot better maintained and will probably supplant ring in future. Ring maintenance seems hostile to use outside of expected use cases.
IshKebab 5mo ago
Yeah on top of that I've seen virtually no evidence that Rust projects really decay. I bet you can compile some really old Rust projects with the latest Rust with no problems. In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is: 1. Go. Very reliable. 2. Rust. Also very reliable. 3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently. 4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently). 5. JavaScript. Good fucking luck.

nothinkjustai 5mo ago

Weird post. One could pick any language OP recommends over Rust and find just as many if not more reasons not to use it.

pornel 5mo ago

It's a rehash of a bunch of old misconceptions. I thought we've buried these when people got actual experience with Rust. The dumbest one is counting changelog lines. Have you even read them? These days most of them are "obscure libstd function is now allowed in const contexts". The regular Rust releases include compiler improvements, libstd evolution, and build system tweaks. Nobody's saying C keeps changing because LLVM has a long changelog or CMake added a new feature.

tialaramex 5mo ago
I agree but more common than "Now allowed in const context" is "This new type/method/free function is now stabilized" e.g. in 1.95 they stabilized a bunch of "Atomic update" methods such as: AtomicPtr::update which is a nicer way to write one of those "Get the pointer, do some stuff to calculate a new value from the old one, then try to swap its old value for the new one, if the pointer changed meanwhile repeat each time with the changed value until we succeed" stanzas some low-level people will have written a hundred times. This library feature does all that boring boilerplate for you, you just write that "calculate a new value" code as a lambda (or function, Rust doesn't mind) and you're done. That's the sort of feature where if it didn't exist when you wrote your code, you go "That's nice" and move on, no change needed, but now that it does exist you might use it in future software you write. If you have a team writing Rust it probably makes sense to have somebody read these changelogs, but that's about it.
- saghm 5mo ago
  I tend the be the one on my team who reads them. I don't think I've ever had a coworker in close to seven years of writing Rust professionally that had trouble because they didn't read them. At most, sometimes I'll suggest using some function I remembered reading about to someone in a code review, and then they'll go "oh, cool!", and use it, and then they don't need to do anything else. Meanwhile, the times that there are useful changes under the hood, you get them in a few weeks instead of maybe some time later in the year or next year. I don't understand at all how someone could plausibly argue that this is a problem in this context. At absolute most, you could argue against some of the downstream effects of the rapid release cycle (like how it reinforces the small standard library size; more surface area means potentially more bugs, and putting out an extra release to fix them when there are already releases so frequently is a hard sell, so it makes sense to keep things slim), but the article doesn't have anywhere close to that level of nuance in addressing the issue, so I'm skeptical that this is even something they've considered.

vld_chk 5mo ago

This is the case, when author argues about the right thing (you do not need Rust everywhere on every project and in every feature, especially if your team has 0 prior exposure to Rust or at least C++), but provide very awkward arguments which are not aligned with core thesis.

pjmlp 5mo ago

Yes, Rust should not be used for everything, like any other language shouldn't, but some devs only see nails. Example Amazon uses Rust mostly for actual systems programming, writing hypervisors and cloud infrastructure low level services. They have plenty of other stuff in there as well.

Panzerschrek 5mo ago

It's not mentioned, that the language itself is designed in such a way, so it requires a lot of boilerplate involving traits. The same results (both safety and speed) are achievable without using traits at all but by relying on duck-typing.

_davide_ 5mo ago

Except rust is way more productive than any other language out there...

worik 5mo ago
> ...rust is way more productive than any other language... Eventually The learning curve is unfun

joshka 5mo ago

Every single one of this authors articles that I've read (and it's a fair few), are poorly argued, and generally incorrect. It would be easy to engage and disprove, but it's better not to give this air. Just say no to kerkour.

throwa356262 5mo ago

"Rust's biggest weakness: an anemic standard library" As someone who programs in both go and rust, I could not agree more.

zesterer 5mo ago

This is largely FUD, written with the intent of sounding professional and with expertise, but in practice there are many tell-tale signs that the author doesn't really know what they're talking about. > the biggest drawback of async is the fragmentation of the ecosystem 95% of the ecosystem uses tokio nowadays. async-std has been dead for a long while. There are other runtimes for specialist purposes, but pretty much all async libraries will work with tokio, and you should just use tokio. It's fine. It's well maintained. It's not going anywhere. It's hit a stable 1.0. There is basically no reason to not use it. > So, if you think that you didn't have enough work solving the problems of your users, you now also need to update your toolchains, Dockerfiles, dependencies and more, every 6 weeks. This is complete rubbish. Rust's edition system means that Rust code written back in 2015 will (largely, bar some minor soundness issues that have been found since then) still compile. You're under no compulsion to update anything, and cargo's lockfiles ensure that your builds don't suddenly break. If you want to upgrade, do so! But it's exceedingly rare that code ever needs to change when doing so. It's about a painless an upgrade experience as it's possible to have in this industry. > Rust is betting everything on a powerful language backed by advanced theory, but it forgot that developers need more than a language to build solutions to businesses' problems. No, it didn't. Rust's standard library is not designed to give you everything you need to build a large program. Instead, it's designed to specify the interfaces that other libraries in the ecosystem require to talk to one-another, and it's been remarkably successful at that. Take a scroll through [the docs](https://doc.rust-lang.org/std/ https://doc.rust-lang.org/std/) and you'll see that: it's almost all traits, fundamental types, and other shared abstractions that are used by the rest of the ecosystem. Any non-trivial program is supposed to end up with third-party dependencies: the critical thing is that those dependencies can talk to one-another painlessly, and that promise is largely delivered upon: everybody uses the same interface for `Future`, `Iterator`, `From/`Into`, `Allocator`, `Clone`, `Eq`/`Cmp`/`Hash`/`Ord`, `Error`, `Debug`/`Display`/`FromStr`/`ToString`, `Read`/`Write`, `Sync`/`Send`. That's the sign of a remarkably successful and well-engineered set of abstractions.

worik 5mo ago
> 95% of the ecosystem uses tokio nowadays The other 5% matters a lot. > but pretty much all async libraries will work with tokio, "pretty much" is useful until it's not. When it's not it is a special type of hell

grougnax 5mo ago

Rust has no limits. You do have limits.

dev_l1x_be 5mo ago

I am not sure how many times RIIR helped me, my customers, teams to achieve better outcomes. Energy use matters. Memory safety matters. ML (Meta Language) features are a bliss to C/C++ languages. With the coding agents picking up Rust is much easier than it was 5 years ago. I am not sure what impact the lack of crypto primitives in the standard library even has. I can use hashing (even the more advanced ones like blake3) and some of the NACL primitives and that is fine. Async Rust is a bit hard, I agree. Function coloring is probably not the best, but I am not sure how to not have that in a compiled language like Rust, or how to improve it.

djmunro 5mo ago

[flagged]

NuSkooler 5mo ago

I've now worked with 3 teams that have moved from Python (2/3) and C++ (1/3) to (async) Rust. All successfully, all with less bugs, moving faster, etc. And now we have AI.