Live data from Hacker News

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

kerkour.com

11–20 of 93 posts

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

#11
post #2

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…

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.

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

#12

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.

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.

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

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

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

#15

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, an…

The annoying thing about Rust, or at least the hype around Rust, is that people want to in use it for bloody everything.

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.

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

#16

> 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 b…

Ring is a de facto standard for better or worse. In our codebase we basically have no choice but to use it

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

#17
post #5

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 ba…

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.

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

#18

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, an…

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.

I have been churning away writing a custom backed in rust using Dioxus, it is excellent for this kind of high level work.

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

#19
post #15

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, an…

The annoying thing about Rust, or at least the hype around Rust, is that people want to in use it for bloody everything. 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 havin…

Because the attraction of rust is powerful. The same toolkit allows you to write code for a microcontroller or a full fat arm webserver, the rules are the same and the language is strong.

The best bit about writing rust is the reason why it kinda sucks for corporations. You can "finish" your code

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

#20

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.

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.

Post reply on HN