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

261–270 of 273 posts

Re: Async Rust never left the MVP state

#261

Post by jandrewrogers »

andriy_koval wrote: post #256
jandrewrogers wrote: post #180

Earlier quoted context omitted.

Yes, and it is extremely expensive. This is a well-known design problem in database engines. The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points. To address this you either need fewer yield points, which reduces concurrency, or you need to greatly reduce the cost of yielding. An async architecture reduces the cost of yie…

> The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points. I would they this often is 1% of cases. As for Rust ecosystem, it doesn't make much case to add so much complexity and inconvenient abstractions to cover 1% of use-cases.

It approaches 100% of cases for systems that care about software performance, since software performance is bandwidth bound. If almost everyone agrees that software performance is optimally fast already then I agree with you.

Re: Async Rust never left the MVP state

#262

Post by dragochat »

usrnm wrote: post #204
dana321 wrote: post #142

Earlier quoted context omitted.

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.

And then you want to do something trivial like an async callback

> trivial like an async callback

can't for the love of dog parse the meaning of this - what do you mean? a callback that is async passed to a sync api? you refer to the complexity of syncasync bridging? ...or?

Re: Async Rust never left the MVP state

#263

Post by usrnm »

dragochat wrote: post #262
usrnm wrote: post #204

Earlier quoted context omitted.

And then you want to do something trivial like an async callback

> trivial like an async callback can't for the love of dog parse the meaning of this - what do you mean? a callback that is async passed to a sync api? you refer to the complexity of sync async bridging? ...or?

Just pass it around, store it and then call it. What type does it have? AsyncFn is still an experimental API.

Re: Async Rust never left the MVP state

#264

Post by surajrmal »

steveklabnik wrote: post #260
xpe wrote: post #253

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. Hi. The article calls Rust async an MVP. You should expect strong reactions when you frame it like that. "MVP" has a generally understood meaning; distorting that is unhelpful and confusing. Rust's async was not an MVP when it was released in 2019. It was the result of a lot of earlier work. Rust as…

> Rust's async was not an MVP when it was released in 2019 The team literally described it as such. One of the main architects of Rust’s async/await, withoutboats, left a comment on lobsters: > It's just the truth. Neither in the language design nor in the compiler implementation has hardly any progress been made in the now 7 years since we shipped the MVP. The people primarily involved in delivering the MVP all beco…

Arguably the state it was left in is the state that was sufficient for the needs of all adopters. Don't fix something if it ain't broke. I know it's been sufficient for fuchsia which did a lot of the initial investment. The types of improvements described in the post tend to only matter at scale or in embedded use cases. No one from those realms has decided it was a sufficiently important problem to prioritize solving until now so it didn't get solved.

Even if MVP is the correct term for its current state, it has a connotation to it which less informed folks will take away the wrong meaning from, so perhaps it's not useful to continue to propagate it even if true.

Re: Async Rust never left the MVP state

#265

Post by andriy_koval »

jandrewrogers wrote: post #261
andriy_koval wrote: post #256

Earlier quoted context omitted.

> The computational cost of context-switching threads at yield points is often many times higher than the actual workload executed between yield points. I would they this often is 1% of cases. As for Rust ecosystem, it doesn't make much case to add so much complexity and inconvenient abstractions to cover 1% of use-cases.

It approaches 100% of cases for systems that care about software performance, since software performance is bandwidth bound. If almost everyone agrees that software performance is optimally fast already then I agree with you.

There is perfect performance and there is performance good enough, which is 99% of cases, where adding complexity is not justified.

Re: Async Rust never left the MVP state

#266

Post by steveklabnik »

surajrmal wrote: post #264
steveklabnik wrote: post #260

Earlier quoted context omitted.

> Rust's async was not an MVP when it was released in 2019 The team literally described it as such. One of the main architects of Rust’s async/await, withoutboats, left a comment on lobsters: > It's just the truth. Neither in the language design nor in the compiler implementation has hardly any progress been made in the now 7 years since we shipped the MVP. The people primarily involved in delivering the MVP all beco…

Arguably the state it was left in is the state that was sufficient for the needs of all adopters. Don't fix something if it ain't broke. I know it's been sufficient for fuchsia which did a lot of the initial investment. The types of improvements described in the post tend to only matter at scale or in embedded use cases. No one from those realms has decided it was a sufficiently important problem to prioritize solvin…

> No one from those realms has decided it was a sufficiently important problem to prioritize solving until now so it didn't get solved.

This is both true and not true. It's no secret that the async ecosystem has had deep social rifts for a very long time, and that's made it very tough to actually make progress by anyone, regardless of the desire to.

It is true that async massively gave a boost to Rust's adoption, and it is good enough for many users. It is a monumental technical achievement. At the same time, that doesn't mean it's perfect.

Re: Async Rust never left the MVP state

#267

Post by 3836293648 »

ignoreusernames wrote: post #66

Agree with the other commenters that the title is a bit too dramatic. The content was well written and got the point across. I still don’t have enough experience to have a strong opinion on Rust async, but some things did standout. On the good side, it’s nice being able to have explicit runtimes. Instead of polluting the whole project to be async, you can do the opposite. Be sync first and use the runtime on IO “edge…

Everyone doesn't use tokio. Almost everyone on desktop/server uses tokio, with a few macos specific things wrapping grand central dispatch. But the embedded world is full of custom runtimes.

Re: Async Rust never left the MVP state

#268

Post by ptx »

mike_hearn wrote: post #243
ptx wrote: post #195

Earlier quoted context omitted.

No, JetBrains use Swing in IntelliJ IDEA. You can tell from how it (for example) fails to layout dialogs correctly the first time they're displayed, just like every other Swing application. And how windows have no minimum size because Swing doesn't expose that functionality. And the various baffling bugs involving window focus that are inherent to Swing applications. Eclipse uses SWT instead, which wraps the platform…

When did you last use IntelliJ, 30 years ago? I've never seen it fail to lay out dialogs correctly, windows do have minimum sizes, and I haven't seen any focus bugs.

> lay out dialogs correctly

This might be specific to X11. The initial size of the window is miscalculated when it first opens and a moment later changes by a few pixels, causing the contents to visually shift slightly. This happens with dialog windows the first time they're opened.

> windows do have minimum sizes

My mistake, I meant maximum size.

> and I haven't seen any focus bugs

I was being a bit vague because I've seen lots of different focus bugs on different platforms both decades ago and very recently. For example, it used to be that on Windows, the focus would change to the wrong window if you alt-tabbed too quickly. On X11, very recently, I've ended up in states where the window somehow has focus but not keyboard focus, among other things.

In Sun's own Wireless Toolkit (for J2ME development), which was a Swing application, the keyboard navigation didn't work until you opened a dialog window for the first time, after which it started working.

Re: Async Rust never left the MVP state

#269

Post by xpe »

steveklabnik wrote: post #260
xpe wrote: post #253

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. Hi. The article calls Rust async an MVP. You should expect strong reactions when you frame it like that. "MVP" has a generally understood meaning; distorting that is unhelpful and confusing. Rust's async was not an MVP when it was released in 2019. It was the result of a lot of earlier work. Rust as…

> Rust's async was not an MVP when it was released in 2019 The team literally described it as such. One of the main architects of Rust’s async/await, withoutboats, left a comment on lobsters: > It's just the truth. Neither in the language design nor in the compiler implementation has hardly any progress been made in the now 7 years since we shipped the MVP. The people primarily involved in delivering the MVP all beco…

Sorry, I was too harsh. Or to be more precise: I should not have directed my criticism only at this particular blog post. This topic is a hot mess. Yes, even the 2019 blog post announcing Async Rust [1] used the phrase:

> On this coming Thursday, November 7, async-await syntax hits stable Rust, as part of the 1.39.0 release. This work has been a long time in development -- the key ideas for zero-cost futures, for example, were first proposed by Aaron Turon and Alex Crichton in 2016! -- and we are very proud of the end result. We believe that Async I/O is going to be an increasingly important part of Rust's story.

> While this first release of "async-await" is a momentous event, it's also only the beginning. The current support for async-await marks a kind of "Minimum Viable Product" (MVP). We expect to be polishing, improving, and extending it for some time.

> Already, in the time since async-await hit beta, we've made a lot of great progress, including making some key diagnostic improvements that help to make async-await errors far more approachable. To get involved in that work, check out the Async Foundations Working Group; if nothing else, you can help us by filing bugs about polish issues or by nominating those bugs that are bothering you the most, to help direct our efforts.

---

MVP originated from the lean startup world: the core meaning is to build the smallest thing that validates demand. Async-await (a-a) was so much more than that.

Whoever wrote the blog post wrote "MVP" which leaves a reader wondering: are those scare quotes? [2]

Nice a-a was "in the air" since Go shipped it in 2009. Compiled state machines hit the scene not long after: C# in 2012, Clojure in 2013. So demand did not need validation. As I understand it, probably the biggest driver for Rust a-a was to provide a common foundation for work going forward.

The effort and thinking that went into async/await probably blows away 99.9% of MVPs released out into the world! And I don't think it would be crazy to say Rust's a-a was better than ~80% of even "1.0" products.

I don't want to get bogged down in mere definitions... I'm emphasizing the primary emotional vibe. Using MVP (or "MVP") is a surefire way to conjure the wrong emotional valence. It invites confusion and downplays years of incredible work.

My feeling is that original blog post used that framing because the Rust team is famously open to taking however much time is needed to get things as close to perfect as they know how.

[1]: https://blog.rust-lang.org/2019/11/07/Async-await-stable/

[2]: https://en.wikipedia.org/wiki/Scare_quotes

Re: Async Rust never left the MVP state

#270

Post by pkolaczk »

groundzeros2015 wrote: post #136
repelsteeltje wrote: post #57

Earlier quoted context omitted.

Beware, they are different concepts. Threads offer concurrent execution , async (futures) offer concurrent waiting . Loosely speaking, threads make sense for CPU bound problems, while async makes sense for IO bound problems.

Why? You write the same code with async await but with a keyword at the beginning of every function.

Only if you ever deal with one future at a time. But async allows things like awaiting one of N events in a very natural way. Those patterns are much less readable when done with threads.
Post reply on HN