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

Why asynchronous Rust doesn't work

theta.eu.org

Post reply on HN
Print view View original

41–50 of 499 posts

Re: Why asynchronous Rust doesn't work

#41

Post by devwastaken »

newpavlov wrote: post #37

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

Correct me if I'm wrong, but isnt any sort of async support non integral to rust? For example in something like Javscript you can't impliment your own async. But in C, C++ or Rust you can do pretty much anything you want.

So if in the future io-uring and friends become the standard can't that just be a library you could then use?

Similar to how in C you don't need the standard library to do threads or async.

Re: Why asynchronous Rust doesn't work

#42

Post by joobus »

boulos wrote: post #24

The author admits that they needed Arc/clone in a footnote. So I think the more interesting title would be to rehash/interpret this as “Why asynchronous Rust is too hard”. Having played with this a bit recently, I think folks are going to end up: - assuming Tokio (now that it’s 1.xx) - mark nearly everything as async - push callers to use rt.block_on to wait for an async function from non-async code I definitely miss…

> AFAICT, tokio is basically going to become the default assumption

I've noticed this as well. And then there are the libs that don't support async, like diesel. I lost time trying to find the right combination of libraries for a web project. There are a lot of things I don't like about Go, but this part is easier.

Re: Why asynchronous Rust doesn't work

#43

Post by thombles »

I'm not totally sure what the author is asking for, apart from refcounting and heap allocations that happen behind your back. In my experience async Rust is heavily characterised by tasks (Futures) which own their data. They have to - when you spawn it, you're offloading ownership of its state to an executor that will keep it alive for some period of time that is out of the spawning code's control. That means all data/state brought in at spawn time must be enclosed by move closures and/or shared references backed by an owned type (Arc) rather than & or &mut.

If you want to, nothing is stopping you emulating a higher-level language - wrap all your data in Arc or Arc> and store all your functions as trait objects like Box. You pay for extra heap allocations and indirection, but avoid specifying generics that spread up your type hierarchy, and no longer need to play by the borrow checker's rules.

What Rust gives us is the option to _not_ pay all the costs I mentioned in the last paragraph, which is pretty cool if you're prepared to code for it.

Re: Why asynchronous Rust doesn't work

#44

Post by stormbrew »

lmm wrote: post #23
ironmagma wrote: post #8

> The thing I really want to try and get across here is that *Rust is not a language where first-class functions are ergonomic.* So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Or use `move` (the article does mention this). There are easy paths in most programming languages, and harder paths. Rust is no exception. The fact…

> So... don’t use first-class functions so much? It’s a systems language, not a functional language for describing algorithms in CS whitepapers. Then maybe it was a mistake to adopt an async paradigm from functional languages that relies heavily on the idea that first-class functions are cheap and easy? (FWIW I think Rust was right to pick Scala-style async; it's really the only nice way of working with async that I'…

> maybe it was a mistake to adopt an async paradigm from functional languages

> I think Rust was right to pick Scala-style async

I'm confused by this assertion. I'm more aware of procedural language origins of syntactic async/await than functional? The scala proposal in 2016 for async/await even cites C#'s design (which came in C# 5.0 in 2012) as an inspiration[1].

From there, it appears python and typescript added their equivalents in 2015 [2].

If anything, async-await feels like an extremely non-functional thing to begin with, in the sense that in a functional language it should generally be easier to treat the execution model itself as abstracted away.

[1] https://docs.scala-lang.org/sips/async.html

[2] https://en.wikipedia.org/wiki/Async/await

Re: Why asynchronous Rust doesn't work

#45

Post by newpavlov »

devwastaken wrote: post #41
newpavlov wrote: post #37

A bigger problem in my opinion is that Rust has chosen to follow the poll-based model (you can say that it was effectively designed around epoll), while the completion-based one (e.g. io-uring and IOCP) with high probability will be the way of doing async in future (especially in the light of Spectre and Meltdown). Instead of carefully weighing advantages and disadvantages of both models, the decision was effectively…

Correct me if I'm wrong, but isnt any sort of async support non integral to rust? For example in something like Javscript you can't impliment your own async. But in C, C++ or Rust you can do pretty much anything you want. So if in the future io-uring and friends become the standard can't that just be a library you could then use? Similar to how in C you don't need the standard library to do threads or async.

Yes, you can encode state machines manually, but it will be FAR less ergonomic than the async syntax. Rust has started with a library-based approach, but it was... not great. Async code was littered with and_then methods and it was really close to the infamous JS callback hell. The ergonomic improvements which async/await brings is essentially a raison d'être for incorporating this functionality into the language.

Re: Why asynchronous Rust doesn't work

#46

Post by TheCoelacanth »

hctaw wrote: post #26

I don't think any of this is actually a reason why async rust doesn't work. The function color problem is a bit overblown, it hasn't broken nodejs yet either. Most code is sync, sync can call async and vice versa, and the ecosystem hasn't come tumbling down yet (since most Rust isn't whichever async application runtime for web apps is currently in vogue - its a systems language after all). Either way there are bigger…

Why is it a problem that custom executors are difficult to implement? Most other languages that I'm aware of they wouldn't even be possible to implement.

Re: Why asynchronous Rust doesn't work

#47

Post by theopsguy »

jstrong wrote: post #30

I've been primarily coding in rust since 2018. I never cared for async/await, and I've never used it. (at some point, coding event loops became very natural/comfortable for me, and I have no trouble writing "manual" epoll code with mio/mio_httpc). one nice thing about rust's async/await is, you don't have to use it, and if you don't, you don't pay for it in any way. sure, I run into crates that expect me to bring in…

+1000 in this. You can just use rust like c/c++ if you don’t want to buy into async.

Re: Why asynchronous Rust doesn't work

#48

Post by cormacrelf »

> And then fast forward a few years and you have an entire language ecosystem built on top of the idea of making these Future objects that actually have a load of closures inside4, and all of the problems listed above (hard to name, can contain references which make them radioactive, usually require using a generic where clause, etc) apply to them because of how “infectious” closures are.

No, this is straight up not true. Almost the entirety of the futures ecosystem is built explicitly out of nameable structs that library authors implement Future on. They do not typically have a load of closures inside, usually none at all. The unnameable closures are generally in 'user-space', for stringing new futures together with less friction. There are different tradeoffs, but the ecosystem is not built on a bed of indescribable spaghetti quicksand.

Re: Why asynchronous Rust doesn't work

#49

Post by fulafel »

xiphias2 wrote: post #6

As I read through the database example, I saw that the compiler just caught a multi-threading bug for the author, and instead of being thankful, he’s complaining that Rust is bad. I think he should use a higher level framework, or wait a few years for them to mature, and use a garbage collected language until then.

There wasn't any multi-threading in that example I think.

Re: Why asynchronous Rust doesn't work

#50

Post by roca »

noncoml wrote: post #39

> And, as I said at the start, that makes me kinda sad, because I do actually like Rust. I think that’s the most important part of the article. People like Rust but it’s becoming more complex than C++. But unlike C++ it’s more difficult to pick and choose what you use. Rust’s death will be one by thousand cuts. “I really like the language but can’t justify all that complexity in my new small and simpke project” is wh…

It is in no danger of become as complex than C++. Nowhere near.
Post reply on HN