3 ms·

To pick out one example of what makes it challenging: not all executors place the same type system constraints on tasks they execute. Tokio, for example, is a w

To pick out one example of what makes it challenging: not all executors place the same type system constraints on tasks they execute. Tokio, for example, is a work-stealing executor which requires tasks to implement the `Send` trait so they can be sent between threads, while other executors may never move tasks between threads and therefore don't require the `Send` bound.

lucasyvas 3y ago
Yes, this is a major difference. But at this point, let's be honest - why has most stuff converged on Tokio? IMO it's not for reasons wholly of merit - it additionally won a popularity contest as one of the first movers. Why the popularity contest? Because people want an async executor, but they just want it to work. These people largely don't care about the benefits between different executors. I think they'd like the choice to use a different one, but they'd rather just having something available with async traits that trend toward opinionated. The executor issue is a huge problem, because the ideology of "zero opinion" on executor coupled with "ease of adoption" are completely at odds. I don't think the current trajectory will ever resolve nicely.
- mplanchard 3y ago
  We experimented with both tokio and async-std and picked tokio on the merits. This was ~2 years ago, so things may have changed a bit, but tokio provided a lot more out-of-the-box, and we also wanted a multi-threaded executor so its defaults worked well for us.
- cmrdporcupine 3y ago
  I actually think we have a cultural problem due to the fact that many of the people coming into Rust recently are coming from a "full-stack" webdev background, where "frameworks" are huge, and feels like nobody worries about being coupled to one framework or another, just picking the right one. Which is in large part due to the history of JavaScript and so on. This is an influx of people who sense that tokio is the "right" way to do things -- tutorials, blog posts, example applications, and 3rd party libs all start with tokio... and they're not philosophically against being tied to it. Whereas my own sense of the Rust philosophy is supposed to be one of zero-cost abstractions (when possible), and for the language to provide nuts and bolts that I can assemble myself. My interest is in systems eng. I don't want to be tied specifically into the systems-eng choices that Tokio happens to have already made, even if they might be good ones. I want the ability to choose. It's not healthy, in my opinion, for one entity to dominate choices like this. If this can't be resolved, my sense is that people who have the same impulses as me will choose to either not use async at all, or move on from Rust.
  - lucasyvas 3y ago
    I agree with you 100%, but members of the Rust project have stated in the past that async, in not insignificant ways, is a play to deliberately target the higher level web/service based crowd. So, the cultural issue is partially self-inflicted. I'm not even sure what I want in Rust. All I know is that people have a legitimate gripe being sold on Rust async for high level work, having it ergonomically fall much flatter than it should. It's very hard to satisfy everyone, which they are learning day by day. I do wish for the async story to mature a bit more so the implementors have a chance to show the community how good it can be. But the project needs to consider its messaging to the users it has courted over.
    - steveklabnik 3y ago
      > the higher level web/service based crowd. Not everyone that writes network services is "higher level" or "web".
      - cmrdporcupine 3y ago
        That is entirely fair. But back to the topic -- some of us building network services etc would like options, and not to be tied to a specific async runtime. E.g. I was looking at what it would take to move my code over to monoio. Or anything else. Not going to happen, because too many 3rd party deps mandate tokio. That's not a good situ. I'd as soon rip out async, and optimize the concurrent multithreaded situation myself than be tied down that way. FWIW my day job is on embedded Linux, small systems that sit in tractors. We don't do async Rust. It's all actor-style communicating components. And it works pretty much fine.
        steveklabnik 3y ago
        I hear you, options would be nice for sure. We'll see if making things more generic is in the cards or not, I guess.
- pornel 3y ago
  There’s definitely a network effect that makes everyone converge on tokio. However, I don’t think the situation can be improved by putting an executor in std. That will even more strongly make everyone stick to the standard one. The problem isn’t that it’s hard to pick an executor (you can pick tokio without thinking). The problem is that when someone has a legit reason to use a different executor, it’s hard to avoid dependencies using tokio, and it would be even harder to avoid dependencies using a built-in executor.

lucasyvas 3y ago

Yes, this is a major difference. But at this point, let's be honest - why has most stuff converged on Tokio? IMO it's not for reasons wholly of merit - it additionally won a popularity contest as one of the first movers. Why the popularity contest? Because people want an async executor, but they just want it to work. These people largely don't care about the benefits between different executors. I think they'd like the choice to use a different one, but they'd rather just having something available with async traits that trend toward opinionated. The executor issue is a huge problem, because the ideology of "zero opinion" on executor coupled with "ease of adoption" are completely at odds. I don't think the current trajectory will ever resolve nicely.

mplanchard 3y ago
We experimented with both tokio and async-std and picked tokio on the merits. This was ~2 years ago, so things may have changed a bit, but tokio provided a lot more out-of-the-box, and we also wanted a multi-threaded executor so its defaults worked well for us.
cmrdporcupine 3y ago
I actually think we have a cultural problem due to the fact that many of the people coming into Rust recently are coming from a "full-stack" webdev background, where "frameworks" are huge, and feels like nobody worries about being coupled to one framework or another, just picking the right one. Which is in large part due to the history of JavaScript and so on. This is an influx of people who sense that tokio is the "right" way to do things -- tutorials, blog posts, example applications, and 3rd party libs all start with tokio... and they're not philosophically against being tied to it. Whereas my own sense of the Rust philosophy is supposed to be one of zero-cost abstractions (when possible), and for the language to provide nuts and bolts that I can assemble myself. My interest is in systems eng. I don't want to be tied specifically into the systems-eng choices that Tokio happens to have already made, even if they might be good ones. I want the ability to choose. It's not healthy, in my opinion, for one entity to dominate choices like this. If this can't be resolved, my sense is that people who have the same impulses as me will choose to either not use async at all, or move on from Rust.
- lucasyvas 3y ago
  I agree with you 100%, but members of the Rust project have stated in the past that async, in not insignificant ways, is a play to deliberately target the higher level web/service based crowd. So, the cultural issue is partially self-inflicted. I'm not even sure what I want in Rust. All I know is that people have a legitimate gripe being sold on Rust async for high level work, having it ergonomically fall much flatter than it should. It's very hard to satisfy everyone, which they are learning day by day. I do wish for the async story to mature a bit more so the implementors have a chance to show the community how good it can be. But the project needs to consider its messaging to the users it has courted over.
  - steveklabnik 3y ago
    > the higher level web/service based crowd. Not everyone that writes network services is "higher level" or "web".
    - cmrdporcupine 3y ago
      That is entirely fair. But back to the topic -- some of us building network services etc would like options, and not to be tied to a specific async runtime. E.g. I was looking at what it would take to move my code over to monoio. Or anything else. Not going to happen, because too many 3rd party deps mandate tokio. That's not a good situ. I'd as soon rip out async, and optimize the concurrent multithreaded situation myself than be tied down that way. FWIW my day job is on embedded Linux, small systems that sit in tractors. We don't do async Rust. It's all actor-style communicating components. And it works pretty much fine.
      - steveklabnik 3y ago
        I hear you, options would be nice for sure. We'll see if making things more generic is in the cards or not, I guess.
pornel 3y ago
There’s definitely a network effect that makes everyone converge on tokio. However, I don’t think the situation can be improved by putting an executor in std. That will even more strongly make everyone stick to the standard one. The problem isn’t that it’s hard to pick an executor (you can pick tokio without thinking). The problem is that when someone has a legit reason to use a different executor, it’s hard to avoid dependencies using tokio, and it would be even harder to avoid dependencies using a built-in executor.