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?
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
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.
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.
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.
The Rust-specific async sounds interesting. I should give it a try.
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.
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 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.
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.
I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown
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.
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.
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.
Aurornis•1h ago
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•39m 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, 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•22m ago
Perhaps Python, but Rust went the other way - it had all that stuff built and it was removed.
traderj0e•16m ago
tracker1•12m ago
tracker1•14m ago
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.