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

51–60 of 93 posts

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

#51

Post by mplanchard »

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…

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 flow required for your nifty chain of future combinators, is not too too bad.

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

#52

Post by deepriverfish »

vablings wrote: post #19
scuff3d wrote: post #15

Earlier quoted context omitted.

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

also some of those people probably wanna put "used rust at work" on their resume

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

#53

Post by pjmlp »

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.

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

#54

Post by SkiFire13 »

tracker1 wrote: post #27
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…

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

> And a lot of critical banking infrastructure is written in and running on it

How much of that critical infrastructure runs on .NET Framework as opposed to the latest .NET Core though?

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

#55

Post by Panzerschrek »

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.

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

#57

Post by ameliaquining »

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…

In fairness, the post specifically mentions Amazon and Cloudflare, which are using Rust largely for backend stuff (though also for lower-level systems-y stuff, and I think Go is also a favored backend language at Cloudflare). But yes, other large tech companies (Google and Meta come to mind) are using Rust primarily for the lower-level systems-y stuff, where Go isn't an option and the alternative to Rust is C++. These applications are also less likely to need async and so don't have to deal with that set of rough edges.

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

#58

Post by ameliaquining »

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…

I think part of it is that most of Rust sets a really high standard for polish and good design; developers new to the language are often quite impressed by its expressiveness and by the breadth of bug classes it protects you from, once you get over the initial learning curve. (Not always—some developers never grow to like it, either because it's a bad fit for their use case or because they happen to find its particular forms of ceremony especially off-putting—but the success cases are striking.)

And then you start using async, which is less polished and has more awkward design compromises and more footguns that you only find out about at runtime, and it's a bit of a disappointment by comparison, even if some of the problems aren't worse than what you find in competing languages. This is the vibe you get in the Oxide RFDs about things like futurelock, for example.

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

#60

Post by fulafel »

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…

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)

Post reply on HN