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.
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.
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.
You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use 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
Likewise there's an API to call sync code in async context, it's spawn_blocking (or sometimes block_in_place but, stick with spawn_blocking)
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.
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.
I think majority Java code is just sequential blocking code, and it works just fine.
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-remo...
Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.
(eg 100k threads in 2002: https://lkml.iu.edu/hypermail/linux/kernel/0209.2/1153.html .. where the 32-bit 4 GB limit seemed to be the main obstacle)
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
This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.
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
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.
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.
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?
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.
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.
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.
As someone who programs in both go and rust, I could not agree more.
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.
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.
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.
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.
> 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/) 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.
And now we have AI.
Eventually
The learning curve is unfun
There is no reproducible build of the official rustc binary. They claim they're using a modified version of LLVM.
I am moving my projects to Cangjie, I no longer trust _any_ American piece of software.
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.
We have absolutely no need for it at work. We're writing micro services that run in K8s with no extreme performance requirements. Nobody on the team knows the language (I know it better than the people arguing for it, and I don't know more then the basics). And yet, every couple of weeks, I'm having to talk someone out of switching certain services over to it. It's like a damn disease.
The best bit about writing rust is the reason why it kinda sucks for corporations. You can "finish" your code
No, it's not. It works. Perfect? No, absolutely not. There is plenty you could improve, plenty of rough edges you could smooth out. Stuff that caused us problems at the job I had writing low-ish level machine control services. But it's totally workable and we were able to ship working devices, especially compared to doing async stuff in other most other languages, especially the memory-unmanaged ones.
Kind of like Rust itself, a ton of people have tried it and bounced off it because they couldn't get it working in 10 minutes, and in doing so have declared it impossible/for geniuses only/broken/ecosystem-destroying. The narrative around async Rust is probably 70% meme/bad PR, 30% real, actual issues that could be improved.
I hope this comes off as fair. I don't want to excuse any of the shortcomings, but it's a working, useful tool.
And then you start using async, which is less polished and has more awkward design compromises and more footguns that you only find out about at runtime, and it's a bit of a disappointment by comparison, even if some of the problems aren't worse than what you find in competing languages. This is the vibe you get in the Oxide RFDs about things like futurelock, for example.
I’ll add to it that structured concurrency patterns in async Rust can be legitimately awesome and very fun, once you’ve bounced off the traits in the futures crate enough times to use it in anger. The type system can be annoying, but as usual, it’s almost always technically right, and once you understand the ownership flow required for your nifty chain of future combinators, is not too too bad.
Note: most of what I've used it for has been relatively simple... API's with tokio and axum in rust are emphatically not much more difficult than say C# with FastEndpoints, or JS/TS with Hono. It's a bit different.
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.
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.
The Rust-specific async sounds interesting. I should give it a try.
I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown
If your reference is JS or C#, then Rust's async has more friction and annoying details. But Rust is generally harder due to being low-level and picky about memory management and thread-safety details. In a way it's a compliment that Rust's usability even gets compared to GC languages.
If you compare it to hand-rolling state machines in C, or even callbacks in pre-async Rust, then it's an amazing simplification and a very sweet syntax sugar. Especially when you want async code composable, supporting control flow and cancellation.
If you compare it to naive sync Rust while ignoring the extra capabilities that async adds, then async is more complicated and less feature-complete (Streams have more moving parts than Iterators, generic async closures have trickier syntax than generic sync closures, there are scoped threads but no scoped multi-threaded futures, etc). IMHO the difference isn't large and it's reasonable for what you get.
There's also a view that async/await syntax is fundamentally misguided and shouldn't exist at all. From Rust's perspective that's an agree-to-disagree. Rust tried having green threads first (before 1.0) and decided it was too intrusive and magic for a low-level systems language. Rust tried to make do with just threads, callbacks and macros, but it didn't work well either (user code can't make futures compose and optimize as well without compiler's help, especially when you want borrow checker to work with it).
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
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
# Nested blocks for complex operations
sync:
block: # Task 1 - sequential operations
LoadTexture()
ApplyTexture()
block: # Task 2 - parallel to task 1
LoadSound()
PlaySound()
LoadModel() # Task 3 - parallel to tasks 1 and 2
Weather the winter storms
You will find, true bliss
How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?
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.
(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.)
It's a fine language, just like all the others. I'd rather write a web server in Go and a use C when targeting a micro-controller.
Almost reminds me of a quote I heard about python a long time ago: python is the second-best language for everything, and the "first-best" for nothing.
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)
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://rust-lang.github.io/rfcs/0230-remove-runtime.html