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

101–110 of 273 posts

Re: Async Rust never left the MVP state

#101

Post by meowface »

nixpulvis wrote: post #96
diondokter wrote: post #59

Earlier quoted context omitted.

So on the title, I picked this because it's simply the truth. Since async landed in 2019 or so, not much has changed. Yes, we can have async in traits and closures now. But those are updates to the typesystem, not to the async machinery itself. Wakers are a little bit easier to work with, but that's an update to std/core. As I understand it, the people who landed async Rust were quite burnt out and got less active an…

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.

Re: Async Rust never left the MVP state

#102

Post by Panzerschrek »

> Futures aren't (trivially) inlined

In my programming language I wrote custom pass for inlining async function calls within other async functions. It generally works and allows to remove some boilerplate, but it increases result binary size a lot.

Technically Rust can do the same.

Re: Async Rust never left the MVP state

#103

Post by diondokter »

jurgenburgen wrote: post #98
selfhoster1312 wrote: post #86

Earlier quoted context omitted.

As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from. Retrospectively, i think everyone is satisfied with the adopted syntax.

> Retrospectively, i think everyone is satisfied with the adopted syntax. Maybe it’s a case of agree and commit, since it can’t really be walked back.

Various prominent people have said years after that .await was the correct choice after all

Re: Async Rust never left the MVP state

#104

Post by lukaslalinsky »

nchie wrote: post #19
groundzeros2015 wrote: post #8

Earlier quoted context omitted.

In that sentence I’m referring to the abstract idea of a thread of execution as a model of programming, not OS threads. A green thread implementation could do it too. But what you said about kernel implementation is true. But are we really saying that the primary motivation for async/await is performance? How many programmers would give that answer? How many programs are actually hitting that bottleneck? Doesn’t that…

> But are we really saying that the primary motivation for async/await is performance? Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

It was not for performance reasons, but for scaling up.

Re: Async Rust never left the MVP state

#105

Post by diondokter »

ozgrakkurt wrote: post #99
diondokter wrote: post #47

Earlier quoted context omitted.

Hi, author here. I mention in the blog that I've tried to quickly hack two of the simplest optimizations in the compiler and it resulted in 2%-5% binary size savings in real embedded (async) codebases. And a quick and probably deeply flawed synthetic benchmark on the desktop showed a 3% perf increase. So yes, it does really matter. Keep in mind that optimizations stack. We're preventing LLVM from doing it's thing. So…

Saw that but couldn't find what code it gives that improvement on. Is it some embedded application written with Embassy?

Yes, but I can't share the codebases since they're our client's and proprietary. But there aren't a lot of big embedded codebases that are also open source

Re: Async Rust never left the MVP state

#106

Post by lukaslalinsky »

codedokode wrote: post #35
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…

As I understand, "green threads" are also expensive, for example you either need to allocate a large stack for each "thread", or hook stack allocation to grow the stack dynamically (like Go does), and if you grow the stack, you might have to move it and cannot have pointers to stack objects.

Green threads are fine for large servers with memory overcommit. Even with static stack sizes, you get benefits over OS threads due to the simpler scheduling. But the post was about embedded and green threads really suck there. Only using as much stack as you need for the task is the perfect solution for embedded systems.

Re: Async Rust never left the MVP state

#107

Post by dgellow »

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…

You don’t have threads on embedded, but you want a way to express concurrent waiting. Different problems altogether

Re: Async Rust never left the MVP state

#108

Post by pjc50 »

lukaslalinsky wrote: post #104
nchie wrote: post #19

Earlier quoted context omitted.

> But are we really saying that the primary motivation for async/await is performance? Of course - what else would it be? The whole async trend started because moving away from each http request spawning (or being bound to) an OS thread gave quite extreme improvements in requests/second metrics, didn't it?

It was not for performance reasons, but for scaling up.

That's the same thing?

Re: Async Rust never left the MVP state

#109

Post by LelouBil »

Hendrikto wrote: post #72
vlovich123 wrote: post #20

Earlier quoted context omitted.

> 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 Not really. I’ve observed async code often is written in such a way that it doesn’t maximize how much concurrency can be expressed (eg instead of writing “here’s N I/O operations to do them all concurrently” it’s “for operation X, await process(x)”). However, in a threaded wor…

> threads are inherently and inescapably too heavy weight to express concurrency in an efficient way Your premise is wrong. There are many counterexamples to this.

Can you explain more ? I always heard this.

Re: Async Rust never left the MVP state

#110

Post by zozbot234 »

selfhoster1312 wrote: post #86
mplanchard wrote: post #80

Earlier quoted context omitted.

Some of the burnout no doubt being due to the catastrophizing of every decision by the community and the extreme rhetoric used across the board. Great to see people wanting to get involved with the project, though. That’s the beauty of open source: if it aggravates you, you can fix it.

As an example of this, i remember a huge debate at the time about `await foo()` vs `foo().await` syntax. The community was really divided on that one, and there was a lot of drama because that's the kind of design decision you can't really walk back from. Retrospectively, i think everyone is satisfied with the adopted syntax.

It makes sense that there was a huge debate, because the postfix .await keyword was both novel (no other languages had done it that way before) and arguably the right call. Of course, one can argue that the ? operator set a relevant precedent.
Post reply on HN