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

41–50 of 93 posts

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

#41

Post by pointlessone »

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 dependencies of tokio, no indirect ones, no dependencies on other runtimes, no generic dependents.

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

#42

Post by andriy_koval »

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…

> 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

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

#43

Post by sysguest »

ViewTrick1002 wrote: post #36
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…

Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead. History: This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading. https://github.com/rust…

well rust async is 'still evolving' right now

it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)

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

#44

Post by bryanlarsen »

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…

And all the popular ones include a synchronous interface you can use instead of the async one. If if they don't, you can wrap your calls in spawn_blocking.

You might complain about it pulling in tokio, but that's a very different complaint than having to learn/use async.

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

#45

Post by ViewTrick1002 »

sysguest wrote: post #43
ViewTrick1002 wrote: post #36

Earlier quoted context omitted.

Rust had that, but decided it wasn’t a good enough fit. Which was the motivation to keep exploring and land on the current async implementation which scales from embedded to servers with minimal overhead. History: This RFC proposes to remove the runtime system that is currently part of the standard library, which currently allows the standard library to support both native and green threading. https://github.com/rust…

well rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)

Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored.

For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages.

Like for example, cancellation safety, dealing with "long running" futures, cleanly terminating a program, deadlocks at a distance [1] and others I'm forgetting now.

[1]: https://rfd.shared.oxide.computer/rfd/0609

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

#46

Post by andriy_koval »

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…

> 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

I think majority Java code is just sequential blocking code, and it works just fine.

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

#47

Post by [deleted] »

ViewTrick1002 wrote: post #45
sysguest wrote: post #43

Earlier quoted context omitted.

well rust async is 'still evolving' right now it's better than being stuck, but it's not '100% polished' right now (though some crates do make the experience somewhat more polished: especially dtolnay's crates)

Agree. There's stuff missing, and there are problems which likely are "multiple Phd theses" level to solve cohesively. Either in Rust or a successor language when the problem space has been explored. For me the most annoying part are the footguns async Rust introduces, which Rust generally is blessedly empty of compared to e.g. Go or other languages. Like for example, cancellation safety, dealing with "long running"…

[deleted]

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

#48

Post by tialaramex »

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…

> You shouldn't pick a programming language the team doesn't know. That's common sense, not an argument against Rust.

Actually if your team doesn't know any suitable languages it could make sense to pick Rust because they will cause far fewer accidental fires in Rust.

(Safe) Rust is much more forgiving of "I didn't know that's how computers work" than a language like C or C++ yet it's as close to the metal as they are which may matter for your application.

If you're hiring programmers they probably already know some suitable languages which should strongly influence your choice, but if the team's main expertise is not programming they may take to Rust much easier than you'd expect.

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

#50

Post by vablings »

irishcoffee wrote: post #34
vablings wrote: post #19

Earlier quoted context omitted.

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

Fair points, but this glosses over some of the not-great parts. Cargo isn't great. No sanctioned formal spec isn't great. Compilation times aren't great. Messing around with wrapping foreign types can be a bit of a bear sometimes. It's a fine language, just like all the others. I'd rather write a web server in Go and a use C when targeting a micro-controller. Almost reminds me of a quote I heard about python a long t…

Sure, and that's probably because you are good with both Go and C. for me, I use rust as the hammer, and everything is a nail. Hobbyist vs Employee I guess
Post reply on HN