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

81–90 of 93 posts

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

#81

Post by nextaccountic »

pointlessone wrote: post #41
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…

> 3. You don't need to use async Rust. 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 dependen…

There's an API to call async code in a sync context, it's called block_on. You can just spawn threads and do your block_on on every async API you encounter and go on about your life. Pair it with a good mpsc library for inter thread channels (or just use the stdlib mpsc - even though it's slower and strictly worse than libs, it doesn't matter) and you are good to go

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)

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

#83

Post by lenkite »

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…

> 3. You don't need to use async Rust.

This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.

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

#84

Post by traderj0e »

fulafel wrote: post #60
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…

This take on native threads sounds overly pessimistic. 99% of backends do fine with the nr of native threads you can easily run in a single process at least on Linux. Not sure what the practical limit is now but 10k used to be no problem many years ago. (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)

I believe it's fine when you're tuning it. Nowadays people are more likely to have multiple services waiting on each other to handle a user request, each running in containers on random hardware. Even if it's "monolithic," it's probably not really cause they're waiting on external APIs. They don't want to think about tuning for thread pools too.

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

#85

Post by worik »

lenkite wrote: post #83
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…

> 3. You don't need to use async Rust. This is like saying you don't need to use a Smartphone. Technically, correct, but then you need to live like a caveman.

I do a lot of real-time audio programming in Rust because it is so expressive and the compiler so helpful

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

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

#86

Post by traderj0e »

andriy_koval wrote: post #42
pointlessone wrote: post #41

Earlier quoted context omitted.

> 3. You don't need to use async Rust. 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 dependen…

> Want to build a web app, every more or less popular framework is 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

Java is different. Tomcat's thread pool is the older way. A lot of newer stuff was using something promises-related instead with an event loop. But then recently Java added virtual threads which should obviate the need for that, similar to Go. Rust considered virtual threads but chose against that because it requires a more abstracted runtime like Java and Go have. Great preso on this https://www.youtube.com/watch?v=lJ3NC-R3gSI

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

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

#87

Post by worik »

mplanchard wrote: post #51
asa400 wrote: post #24

Earlier quoted context omitted.

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

100% agree with your take, speaking as a professional async rust writer for like five years now. 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 flo…

Surrender, to compile

Weather the winter storms

You will find, true bliss

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

#88

Post by worik »

zesterer wrote: post #72

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…

> 95% of the ecosystem uses tokio nowadays

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

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

#90

Post by ghost_pepper »

worik wrote: post #88
zesterer wrote: post #72

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…

> 95% of the ecosystem uses tokio nowadays 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

I've been writing Rust backend services for years and the 5% has never mattered, I don't even bother checking if things advertise tokio support. Which ones in particular caused you trouble?
Post reply on HN