4 ms·

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 clos

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 and no one has picked up the torch. (Though there's 1 PR open from some google folk that will optimize how captured variables are laid out in memory, which is really nice to have) Since I and the people I work with are heavy async users, I think it's maybe up to me to do it or at least start it. Free as in puppy I guess. So yeah, the title is a little baitey, but I do stand behind it.

mplanchard 5mo ago
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.
- selfhoster1312 5mo ago
  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.
  - jurgenburgen 5mo ago
    > 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.
    - diondokter 5mo ago
      Various prominent people have said years after that .await was the correct choice after all
      - staticassertion 5mo ago
        I'm not prominent but I disagreed with it at the time and I was wrong.
        adastra22 5mo ago
        I’m curious - why were you wrong? It still seems like a wart to me, all these years later. What am I missing?
        tracker1 5mo ago
        Contrast it with async in JS/ES as an example... now combine it with the using statement for disposeAsync instances. await using db = await sqlite.connect(await ctx.getConfig("DB_CONN")); It's not so bad when you have one `await foo` vs `foo.await`, it's when you have several of them on a line in different scopes/contexts. Another one I've seen a lot is... const v = await (await fetch(...)).json(); Though that could also be... const v = await fetch(...).then(r => r.json()); In any case, it still gets ugly very quickly.
        adastra22 5mo ago
        I’ve never in my life used JS, so I’ll have to take your word for it.
        tracker1 5mo ago
        It's a language I'm familiar with that uses the `await foo` syntax and often will see more than one in a line, per the examples given. C# is the most prominent language that has similar semantics that I know well, but is usually less of an issue there.
  - zozbot234 5mo ago
    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.
nixpulvis 5mo ago
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.
- meowface 5mo ago
  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.
  - nixpulvis 5mo ago
    One of Rust's central design goals is to allow zero cost abstractions. Unifying the async model by basically treating all code as being possibly async would make that very challenging, if not impossible. Could be an interesting idea, but not currently tenable. One problem I have with systems like gevent is that it can make it much harder to look at some code and figure out what execution model it's going to run with. Early Rust actually did have a N:M threading model as part of its runtime, but it was dropped. I think one thing Rust could do to make async feel less like an MVP is to ship a default executor, much like it has a default allocator.
    - tracker1 5mo ago
      They could still come in a step short of default executor and establish some standard traits/types that are typical across executors. By providing a default, I think you're going to paint yourself into a corner. Maybe have one of two opt-in executors in the box... one that is higher resource like tokio and one that is meant for lower resource environments (like embedded).
  - jolux 5mo ago
    Rust originally came with a green thread library as part of its primary concurrency story but it was removed pre-1.0 because it imposed unacceptable constraints on code that didn’t use it (it’s very much not a zero cost abstraction). As an Elixir + Erlang developer I agree it’s a great programming model for many applications, it just wasn’t right for the Rust stdlib.
refulgentis 5mo ago
As an uninterested 3rd party, it’s a wild exaggeration
xpe 5mo ago
> 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 async: (a) works well for a lot of people and orgs in production settings and (b) is arguably better designed than most (all?) other async implementations. Calling it an MVP is far from "simply the truth". It is an opinion -- and frankly a pretty clickbaity one. I appreciate your article's attention to detail, but the title is straight up shameful sensationalism. I strive to not reflexively defend the status quo, but I get really chafed when people conveniently blur the difference between fact and opinion. Please argue on narrowest correct claims available. The current title overstates your claims and undermines its overall credibility. Your central claim (as I read it) is that for embedded software there are opportunities for async improvement in Rust. Yeah this might sound boring, but I think it's accurate. My other main criticism of your article is when it claims Rust async breaks the "zero cost abstraction" principle. I don't buy this claim, because you do not show that hand rolling the code provides the same guarantees. A lot of people misunderstand what "zero cost" means; your article wouldn't be the first to give the wrong impression. Writing is hard (different audiences bring different backgrounds), and I commend anyone who puts their ideas out into the world. Please take this as constructive feedback: please agree or disagree with me on the merits. Ask and engage where I'm unclear.
- steveklabnik 5mo ago
  > 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 become less active in the project around the same time and delivery since then has stalled out. > > I hope this person receives the support to do this work. Rust’s async is great, and I feel you around some of the less informed criticisms. But it’s been called an MVP for a decade now, it’s not an insulting characterization. Just because it’s been an MVP does not mean it’s not good or useful.

mplanchard 5mo ago

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.

selfhoster1312 5mo ago
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.
- jurgenburgen 5mo ago
  > 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.
  - diondokter 5mo ago
    Various prominent people have said years after that .await was the correct choice after all
    - staticassertion 5mo ago
      I'm not prominent but I disagreed with it at the time and I was wrong.
      - adastra22 5mo ago
        I’m curious - why were you wrong? It still seems like a wart to me, all these years later. What am I missing?
        tracker1 5mo ago
        Contrast it with async in JS/ES as an example... now combine it with the using statement for disposeAsync instances. await using db = await sqlite.connect(await ctx.getConfig("DB_CONN")); It's not so bad when you have one `await foo` vs `foo.await`, it's when you have several of them on a line in different scopes/contexts. Another one I've seen a lot is... const v = await (await fetch(...)).json(); Though that could also be... const v = await fetch(...).then(r => r.json()); In any case, it still gets ugly very quickly.
        adastra22 5mo ago
        I’ve never in my life used JS, so I’ll have to take your word for it.
        tracker1 5mo ago
        It's a language I'm familiar with that uses the `await foo` syntax and often will see more than one in a line, per the examples given. C# is the most prominent language that has similar semantics that I know well, but is usually less of an issue there.
- zozbot234 5mo ago
  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.

nixpulvis 5mo ago

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.

meowface 5mo ago
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.
- nixpulvis 5mo ago
  One of Rust's central design goals is to allow zero cost abstractions. Unifying the async model by basically treating all code as being possibly async would make that very challenging, if not impossible. Could be an interesting idea, but not currently tenable. One problem I have with systems like gevent is that it can make it much harder to look at some code and figure out what execution model it's going to run with. Early Rust actually did have a N:M threading model as part of its runtime, but it was dropped. I think one thing Rust could do to make async feel less like an MVP is to ship a default executor, much like it has a default allocator.
  - tracker1 5mo ago
    They could still come in a step short of default executor and establish some standard traits/types that are typical across executors. By providing a default, I think you're going to paint yourself into a corner. Maybe have one of two opt-in executors in the box... one that is higher resource like tokio and one that is meant for lower resource environments (like embedded).
- jolux 5mo ago
  Rust originally came with a green thread library as part of its primary concurrency story but it was removed pre-1.0 because it imposed unacceptable constraints on code that didn’t use it (it’s very much not a zero cost abstraction). As an Elixir + Erlang developer I agree it’s a great programming model for many applications, it just wasn’t right for the Rust stdlib.

refulgentis 5mo ago

As an uninterested 3rd party, it’s a wild exaggeration

xpe 5mo ago

> 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 async: (a) works well for a lot of people and orgs in production settings and (b) is arguably better designed than most (all?) other async implementations. Calling it an MVP is far from "simply the truth". It is an opinion -- and frankly a pretty clickbaity one. I appreciate your article's attention to detail, but the title is straight up shameful sensationalism. I strive to not reflexively defend the status quo, but I get really chafed when people conveniently blur the difference between fact and opinion. Please argue on narrowest correct claims available. The current title overstates your claims and undermines its overall credibility. Your central claim (as I read it) is that for embedded software there are opportunities for async improvement in Rust. Yeah this might sound boring, but I think it's accurate. My other main criticism of your article is when it claims Rust async breaks the "zero cost abstraction" principle. I don't buy this claim, because you do not show that hand rolling the code provides the same guarantees. A lot of people misunderstand what "zero cost" means; your article wouldn't be the first to give the wrong impression. Writing is hard (different audiences bring different backgrounds), and I commend anyone who puts their ideas out into the world. Please take this as constructive feedback: please agree or disagree with me on the merits. Ask and engage where I'm unclear.

steveklabnik 5mo ago
> 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 become less active in the project around the same time and delivery since then has stalled out. > > I hope this person receives the support to do this work. Rust’s async is great, and I feel you around some of the less informed criticisms. But it’s been called an MVP for a decade now, it’s not an insulting characterization. Just because it’s been an MVP does not mean it’s not good or useful.