4 ms·

It definitely works just fine

m_a_g 4y ago
You can find great examples of Rust async programming being "a disaster and a mess". You still can consider it is working just fine, but I disagree.
- staticassertion 4y ago
  I don't really need to find those examples, I've written most of my company's product in Rust using async, for years, and it's never once been an issue. That's 100s of thousands of lines of rust written and 0 async issues.
  - clpm4j 4y ago
    Totally valid, but you could also say the same thing about C and C++, i.e. you can wield your tool with mastery, then that's awesome. But I think the average startup would likely struggle needlessly when they really just need to ship products that people want/need to use. Rust is likely not the smartest choice for the average startup.
    - staticassertion 4y ago
      Only one person at the company had previous professional experience with Rust. The majority had 0 experience with it at all. We've had no trouble and it's actually been our most productive language - we're moving away from Python and Typescript where possible.
      - deleted 4y ago
        [deleted]
olalonde 4y ago
My main issue with Rust async was that it wasn't possible to write a "runtime agnostic" libraries. For example, I wrote an HTTP client with Tokio and later wanted to use it in a project that was using another runtime (I think it was async-std) and couldn't use it. I wonder if that has changed since then?
- staticassertion 4y ago
  This is probably more of a concern for people who aren't writing services/ professional devs. Otherwise, who cares, you pick a runtime (tokio) and you use it - runtime agnosticism isn't a real goal for any company.
  - deleted 4y ago
    [deleted]
- nicoburns 4y ago
  That's basically only a problem if you use async-std (just don't, and switch your project if you have). Pretty much everything supports tokio (or there is a just-as-good equivalent library that supports tokio). Which isn't to say this shouldn't be fixed. Just that there's a fairly good away to avoid the problem in practice.

You can find great examples of Rust async programming being "a disaster and a mess". You still can consider it is working just fine, but I disagree.

staticassertion 4y ago
I don't really need to find those examples, I've written most of my company's product in Rust using async, for years, and it's never once been an issue. That's 100s of thousands of lines of rust written and 0 async issues.
- clpm4j 4y ago
  Totally valid, but you could also say the same thing about C and C++, i.e. you can wield your tool with mastery, then that's awesome. But I think the average startup would likely struggle needlessly when they really just need to ship products that people want/need to use. Rust is likely not the smartest choice for the average startup.
  - staticassertion 4y ago
    Only one person at the company had previous professional experience with Rust. The majority had 0 experience with it at all. We've had no trouble and it's actually been our most productive language - we're moving away from Python and Typescript where possible.
    - deleted 4y ago
      [deleted]

olalonde 4y ago

My main issue with Rust async was that it wasn't possible to write a "runtime agnostic" libraries. For example, I wrote an HTTP client with Tokio and later wanted to use it in a project that was using another runtime (I think it was async-std) and couldn't use it. I wonder if that has changed since then?

staticassertion 4y ago
This is probably more of a concern for people who aren't writing services/ professional devs. Otherwise, who cares, you pick a runtime (tokio) and you use it - runtime agnosticism isn't a real goal for any company.
- deleted 4y ago
  [deleted]
nicoburns 4y ago
That's basically only a problem if you use async-std (just don't, and switch your project if you have). Pretty much everything supports tokio (or there is a just-as-good equivalent library that supports tokio). Which isn't to say this shouldn't be fixed. Just that there's a fairly good away to avoid the problem in practice.