FRESH

Hacker News

Home

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

83 points by randomint64

by Aurornis

5 subcomments

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.

by ben-schaaf

3 subcomments

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

by joshka

0 subcomment

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.

by dev_l1x_be

0 subcomment

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.

by cbsmith

0 subcomment

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.

by throwa356262

0 subcomment

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

by egorelik

3 subcomments

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.

by traderj0e

4 subcomments

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.

by pjmlp

0 subcomment

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.

by pornel

1 subcomments

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.

by zesterer

1 subcomments

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

by vld_chk

0 subcomment

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.

by grougnax

0 subcomment

Rust has no limits. You do have limits.

by Panzerschrek

0 subcomment

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.

by irishcoffee

3 subcomments

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?

by NuSkooler

0 subcomment

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.

by unethical_ban

0 subcomment

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.

by nothinkjustai

0 subcomment

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

by _davide_

1 subcomments

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

by djmunro

0 subcomment

[flagged]

by gamander2

2 subcomments

Nobody has ever seen or heard Wesley Wiser talk. Supposedly he's the rust compiler team lead. I claim he's an NSA front end. Prove me wrong.
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.