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

61–70 of 93 posts

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

#61

Post by moomin »

SkiFire13 wrote: post #54
tracker1 wrote: post #27

Earlier quoted context omitted.

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?

IME: less than you’d think. I know one major C# project that’s only half completed its migration and that huge (both in terms of what’s been achieved and what still needs doing). There’s another that keeps it for the front end because it runs on >10,000 client machines. All the others, big or small, have migrated with small carve-outs for stuff .NET Core doesn’t and probably never will support.

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

#62

Post by tracker1 »

SkiFire13 wrote: post #54
tracker1 wrote: post #27

Earlier quoted context omitted.

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?

From recent experience I'd put it slightly higher on the old framework, but plenty of new dev on v5+ and I think sticking on framework is worse at this point.

Though I would say that breaking changes since Core 3 have been pretty limited. V5 unified .net under the new core as the path forward for framework users as well.

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

#64

Post by IshKebab »

ben-schaaf wrote: post #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 b…

Yeah on top of that I've seen virtually no evidence that Rust projects really decay. I bet you can compile some really old Rust projects with the latest Rust with no problems.

In my experience the "oh god I have to compile a 10 year old program" dread hierarchy (from least to most dread) is:

1. Go. Very reliable.

2. Rust. Also very reliable.

3. C++. Sometimes stuff breaks, e.g. when they change the default C/C++ version and dependencies don't specify it. That happened to me recently.

4. Python. They deprecate stuff all the time that is often actually used (e.g. a load of stuff in pkgutil recently).

5. JavaScript. Good fucking luck.

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

#66

Post by simon_void »

bryanlarsen wrote: post #44
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…

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.

Is the inclusion of synchronous interfaces a new thing? When I learned actix_web 2-3 years ago for some webservices at work, the documentation surely (at least) started of with async functions everywhere. Did that change? Were synchronous interfaces introduced later in the actix_web documentation? Or did everybody switch over to axum in the meantime and axum has synchrounous interfaces!? (I just checked and according to crates.io axum seems to have 8x the recent downloads of actix_web.) background: actix_web is still the only Rust webframework I have experience with

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

#67

Post by danhau »

bryanlarsen wrote: post #44
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…

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.

Dependencies having to pull in tokio is an even larger issue, indicating that async‘s promise of „bring your own runtime“ is a bit of a lie. Lovely, lovely dependency hell.

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

#68

Post by tancop »

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…

the best async/concurrency model i know is verse [1], a language made for fortnite scripting because tim sweeney decided he wants something with "metaverse" in the name. instead of async/await or verbose callbacks its all combinators. from their docs:

  # Nested blocks for complex operations
  sync:
    block:  # Task 1 - sequential operations
        LoadTexture()
        ApplyTexture()
    block:  # Task 2 - parallel to task 1
        LoadSound()
        PlaySound()
    LoadModel()  # Task 3 - parallel to tasks 1 and 2
[1] https://verselang.github.io/book/14_concurrency/#structured-...

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

#69

Post by jen20 »

tracker1 wrote: post #28
traderj0e wrote: post #25

Earlier quoted context omitted.

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.

While true, this isn’t what I’m talking about: Rust had _built in_ green threads at one point, the same as Go [1].

[1]: https://rust-lang.github.io/rfcs/0230-remove-runtime.html

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

#70

Post by jen20 »

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.

True now, but there was a time when async/await was _not_ part of Rust, and a runtime was.
Post reply on HN