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

A four year plan for async Rust

without.boats

Post reply on HN
Print view View original

41–50 of 236 posts

Re: A four year plan for async Rust

#41

Post by steveklabnik »

dgacmu wrote: post #37
the__alchemist wrote: post #3

Earlier quoted context omitted.

I'm with you. I feel like an outcast in the Rust OSS embedded circles when I bring this up. They are heavily into async/embassy.

I'm curious why you don't like it for embedded - embassy has been an absolute delight for me thus far, and my primary complaint about it is just that it doesn't have the breadth of hardware support (yet?). It's been the thing that has redeemed Rust async for me, as otherwise, I tend to find the tension the author notes frustrating as well.

I am pro async Rust, but we don't use async in our embedded projects at Oxide. This is because of specific design constraints and goals: https://hubris.oxide.computer/reference/#_why_synchronous

That being said, I am also a fan of embassy when you have different design constraints and goals, and consider the fact that is is able to exist and be successful is a massive testament to the design of async Rust.

(We also use async Rust heavily further up the stack, and have some issues with it, but they tend to be disjoint from the way that this is talked about online.)

Re: A four year plan for async Rust

#43

Post by the__alchemist »

dgacmu wrote: post #37
the__alchemist wrote: post #3

Earlier quoted context omitted.

I'm with you. I feel like an outcast in the Rust OSS embedded circles when I bring this up. They are heavily into async/embassy.

I'm curious why you don't like it for embedded - embassy has been an absolute delight for me thus far, and my primary complaint about it is just that it doesn't have the breadth of hardware support (yet?). It's been the thing that has redeemed Rust async for me, as otherwise, I tend to find the tension the author notes frustrating as well.

What I like about Embassy is the Metapac, and less reliance on generics and typestates than predecessors.

My complaint is I don't find the async ergonomics intuitive; it feels like a layer of misdirection. And, the viral character.

Re: A four year plan for async Rust

#44

Post by sapiogram »

withoutboats3 wrote: post #13
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

What Rust libraries use async that you think should not? I can think of one, but otherwise every library I've encountered uses async because its intended for the kind of networking service that benefits from using non-blocking IO.

I had an absolutely awful experience when I tried using Sqlite through the sqlx crate. The work was mostly cpu-bound, but I didn't mind blocking the event loop for a few seconds here and there, so I thought I would just run it on Tokio's worker threads. Big mistake, I ended up getting extremely low CPU utilization due to a quirk (Or less charitably, a bug) in Tokio's scheduler.

I eventually rewrote the whole thing with rusqlite, but apart from being non-async, I found the API much less ergonomic to work with. But at least Rayon worked exactly as I expected.

Re: A four year plan for async Rust

#47

Post by no_wizard »

inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I will forever argue that things like goroutines and the Java Loom Project are proving that it is long term more successful than making an explicit async keyword / operation that has its own semantics when invoked, because it won't dictate your code and cause the color function problem to exist.

I'd love to see this in Rust, and I know that it initially had something like this, perhaps its not a bad idea for someone to take a second look at this now that more time has passed.

EDIT: to be clear, that is not me saying we need goroutines or we need a Java Loom equivalent in Rust, simply, the DX of these two examples are far superior to the DX of async Rust today, in my opinion

Re: A four year plan for async Rust

#48

Post by withoutboats3 »

no_wizard wrote: post #47
inamberclad wrote: post #2

Async is a huge wart and I try and avoid it wherever possible. It's simply not useful in a lot of cases that I encounter. However, if a library uses async, you have little choice but to make your whole project async. This adds to its horrible reputation.

I will forever argue that things like goroutines and the Java Loom Project are proving that it is long term more successful than making an explicit async keyword / operation that has its own semantics when invoked, because it won't dictate your code and cause the color function problem to exist. I'd love to see this in Rust, and I know that it initially had something like this, perhaps its not a bad idea for someone…

This was the subject of my previous post: https://without.boats/blog/why-async-rust/

Re: A four year plan for async Rust

#49

Post by steveklabnik »

lucasyvas wrote: post #40

I think std needs a default runtime, and we might as well make it tokio, but maybe make the single-threaded executor the default instead and tweak the API where appropriate to align with this change. Swapping the executors out should absolutely be a feature, and the traits should be portable, but a way to start fixing the situation beyond the great suggestions in this proposal is to acknowledge that std and no-std us…

> I think std needs a default runtime, and we might as well make it tokio

Regardless of the quality of this idea, it isn't going to happen: neither the Rust Project nor Tokio (in my understanding, to be clear I am not involved in either) want this to happen.

> Swapping the executors out should absolutely be a feature, and the traits should be portable

I am not fully aware of all of the details here but there are significant problems when it comes to actually getting this done; I don't think anyone is ideologically opposed, but there's a lot of practical considerations that make this difficult, in my understanding.

Re: A four year plan for async Rust

#50

Post by zozbot234 »

Verdex wrote: post #38
lucasyvas wrote: post #20

Earlier quoted context omitted.

This is consistent with the author's assessment - the incomplete implementation of async makes it very challenging to advocate for, despite the fact that it was the only logical choice given Rust's design goals. I will say that the notion that you must make your whole project async is largely true (except that you can block on futures with all runtimes), but this is more symptomatic of the fact that Rust has hitched…

> It's equally desired at "web server and above" and "operating system and below", which probably makes it one of the hardest languages on the planet to design. My theory as to why C++ has become as a problematic language as it has is because it is able to do it all. And "all" doesn't fit nicely into a single package or paradigm. I don't like async (in any language), so your post immediately piqued my interest. I'm n…

C++ is problematic in that it's a memory-unsafe language with a lot of cruft dating back to the 1980s. Its generality has made it more not less successful, since that makes it a lot easier to reuse library and support code across domains.
Post reply on HN