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

Async Rust never left the MVP state

tweedegolf.nl

Post reply on HN
Print view View original

141–150 of 273 posts

Re: Async Rust never left the MVP state

#141

Post by selfhoster1312 »

nicoburns wrote: post #112
selfhoster1312 wrote: post #87

Earlier quoted context omitted.

What's the alternative? I'm happy to use tokio, but i'm happy other folks can enjoy other executors (smol, async-std, glommio, etc). I think the situation is OK because tokio is well-maintained, even though it's not part of the standard library, and i'm afraid making it part of the standard library would make it harder to use other executors, and harder to port the standard library to other platforms. But maybe my fe…

> What's the alternative? Traits in the stdlib for common functionality like "spawn" (a task) and things like async timers. Then executors could implement those traits and libraries could be generic over them.

Good point, but the devil lies in the details. How should the timers behave? Is the clock monotonic? Are tasks spawned on the same thread? Different platforms and executors have different opinions. Maybe it's still possible and just a lot of work?

Re: Async Rust never left the MVP state

#142

Post by dana321 »

dragochat wrote: post #124

what's the modern "absolute beginner's guide to async in Rust" - ideally something dense that can bring someone motivated from beginner to expert in ~1 week of intense hacking on it?

It doesn't take a week to learn the async basics.

add async keyword to functions add .await when calling them use tokio in your main function (easy to look up) use the async recursion crate if you need to use recursion but don't want to box everything

There are some bonuses like calling functions in parallel, but there you go.

Re: Async Rust never left the MVP state

#143

Post by simonask »

DeathArrow wrote: post #53

I like it more how Zig is approaching async with the new IO. It avoids function coloring.

Does it, though?

Whether your function has the `async` keyword attached or has a function argument of type `IO` doesn't really change anything substantial.

The whole "function color" argument seems pretty overblown to me. You can't call `foo(int, string)` if you don't have both an int and a string, so is it now a different "color" than the function `bar(int)`? If you want to call `foo` from `bar`, you have to somehow procure a string, and the same is true for `IO` in Zig, and the same is true for async in Rust, where what you have to procure is an async executor.

The `async` keyword can be seen as syntactic sugar for introducing a hidden function parameter (very literally, it's called `&mut std::task::Context`), as well as rewriting the function as a state machine.

Re: Async Rust never left the MVP state

#144

Post by aw1621107 »

groundzeros2015 wrote: post #138
K0nserv wrote: post #81

Earlier quoted context omitted.

I think you are correct, in so far that often N:M threading is overkill for the problem at hand. However, some IO bound problems truly do require it. I haven't kept up with the details, but AFAIK the fallout from Spectre and Meltdown also means context switches are more expensive than they were historically, which is another downside with regular threads. I also want to address something that I've seen in several sub…

I think rust didn’t need async at all.

The question then becomes what, if anything, should take its place, and what are the corresponding tradeoffs?

Re: Async Rust never left the MVP state

#145

Post by [deleted] »

meowface wrote: post #101
nixpulvis wrote: post #96

Earlier quoted context omitted.

I think it's partially accurate, and partially a consequence of how async fractures the design space, so it will always feel like a somewhat separate thing, or at least until we figure out how to make APIs agnostic to async-ness.

I am a beginner to Rust but I've coded with gevent in Python for many years and later moved to Go. Goroutines and gevent greenlets work seamlessly with synchronous code, with no headache. I know there've been tons of blog posts and such saying they're actually far inferior and riskier but I've really never had any issues with them. I am not sure why more languages don't go with a green thread-like approach.

[deleted]

Re: Async Rust never left the MVP state

#146

Post by otabdeveloper4 »

groundzeros2015 wrote: post #4

Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right program…

> Now language runtimes prefer “green threads” for portability and performance

"Green threads" only exist in crappy interpreted languages, and only because they have stop-the-world single-threaded garbage collection.

Re: Async Rust never left the MVP state

#147

Post by nicoburns »

selfhoster1312 wrote: post #141
nicoburns wrote: post #112

Earlier quoted context omitted.

> What's the alternative? Traits in the stdlib for common functionality like "spawn" (a task) and things like async timers. Then executors could implement those traits and libraries could be generic over them.

Good point, but the devil lies in the details. How should the timers behave? Is the clock monotonic? Are tasks spawned on the same thread? Different platforms and executors have different opinions. Maybe it's still possible and just a lot of work?

> Maybe it's still possible and just a lot of work?

Yeah, I think that's the current status. I believe it was for a long time (and possibly still is) blocked on language improvements to async traits (which didn't exist at all until relatively recently and still don't support dyn trait).

Re: Async Rust never left the MVP state

#148

Post by NobodyNada »

InfinityByTen wrote: post #56

I like this article already because it took me to the goals of Rust for 2026. We use the language in our team, but we haven't needed to go very deep to do the stuff we need. Yet, I really enjoy witnessing the development of a language from ground up with so much community feedback. I somehow miss noticing that in C++ and I have no idea how it is working in other domains. My only gripe is that a lot of it is feeling a…

> My only gripe is that a lot of it is feeling a bit kick-starter-y

IMO the term "project goals" is quite misleading for what this actually is. A project goal is a system for one person (or a small group of people) to express that they'd like to work on something and ask for Rust project volunteers to commit ongoing time and effort to supporting them through code review, answering questions, etc. It doesn't mean that the Rust project itself has set the goal, or even necessarily endorsed it.

So it's not quite right to treat it as a formal roadmap for Rust, just a "there are some contributors interested in working on these areas".

Re: Async Rust never left the MVP state

#149

Post by ok123456 »

MrBuddyCasino wrote: post #22
slopinthebag wrote: post #9

It's so funny that people will do anything to hate on Rust, including nitpicking a few bytes of overhead for a future while they reach for an entire thread or runtime to handle async in their favourite language.

Nobody seriously tries to run Golang or Java on an MCU. But they do run Rust code.

J2ME existed before most of the current crop of Rust programmers were born.

Re: Async Rust never left the MVP state

#150

Post by Salgat »

groundzeros2015 wrote: post #4

Async seems like an underbaked idea across the board. Regular code was already async. When you need to wait for an async operation, the thread sleeps until ready and the kernel abstracts it away. But We didn’t like structuring code into logical threads, so we added callback systems for events. Then realized callbacks are very hard to reason about and that sequential control is better. So threads was the right program…

Awaiting allows you to efficiently yield the thread to other tasks instead of blocking it. That's one of its biggest advantages.
Post reply on HN