Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

kerkour.com

Post reply on HN
Print view View original

21–30 of 93 posts

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

#21

Post by traderj0e »

steveklabnik wrote: post #20
traderj0e wrote: post #9

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

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

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

#22

Post by jen20 »

traderj0e wrote: post #11
Aurornis wrote: 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 b…

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

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

#23

Post by pornel »

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.

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

#24

Post by asa400 »

traderj0e wrote: post #9

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.

> Is async in Rust really this bad?

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.

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

#25

Post by traderj0e »

jen20 wrote: post #22
traderj0e wrote: post #11

Earlier quoted context omitted.

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

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

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.

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

#26

Post by Aurornis »

traderj0e wrote: post #9

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.

If someone finds normal ownership concepts in Rust to be difficult, making the leap to async is only going to make that worse.

I don't think it's friendly to Rust beginners but I also think the complaints about if have been overblown

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

#27

Post by tracker1 »

traderj0e wrote: post #11
Aurornis wrote: 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 b…

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.

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

#28

Post by tracker1 »

traderj0e wrote: post #25
jen20 wrote: post #22

Earlier quoted context omitted.

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

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.

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.

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

#29

Post by tracker1 »

asa400 wrote: post #24
traderj0e wrote: post #9

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.

> Is async in Rust really this bad? 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 me…

Funny... I started off with very little knowledge, totally cheated with what I wanted to do by cloning everything crossing various library boundaries and it still worked surprisingly well. Then I learned about (A)RC, Box etc... and I still kinda really hate the lifetime syntax.

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.

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

#30

Post by tialaramex »

egorelik wrote: 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 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.

Post reply on HN