4 ms·

This blog post goes into detail about how technical decisions were made to keep Rust a "systems language." Rust's async/await is even moreso here than C++ corou

This blog post goes into detail about how technical decisions were made to keep Rust a "systems language." Rust's async/await is even moreso here than C++ coroutines, as Rust requires zero allocations and C++ coroutines require at least one (that hopefully could be optimized out but that's not a guarantee.) People use async/await in embedded contexts, with no or tiny heaps, thanks to this careful design. It doesn't get more "systems" than that. The end of the post specifically lays out a space for a "less systems Rust" that would make these features nicer, but that cannot exist in Rust due to its strong commitment to being as zero-overhead as possible. I don't know what it is about this feature that leads to everyone grandstanding all the time. It's incredibly frustrating.

corethree 3y ago
The community needs a language that isn't so extreme that is opinionated on what is zero cost and what is not. Golang sort of fits this bill as it has an opinionated take on this, but overall from my pov it's a bad opinion. No sum types, no namespaces, garbage collection.... I feel it's still the only other language that fills this space that isn't so OOP. It's a bad solution and it's popular because it's the only solution. Anyway to get back to your point, I think this is why so many people complain. It's either go or rust and neither is ideal so one way to deal with the problem is attempting to shape rust into this ideal. Right? Where can I find a language with no garbage collection, nice sum types and no over complicated async syntax? Where? Nowhere. This is what people want.
- Rusky 3y ago
  You can just not write async code in Rust, no? There are a lot of Rust programmers that work this way, and it's fine because async is quite separable from the rest of the language. Even if you have to pull in a dependency that uses async (though if you are not doing async stuff yourself, why would you??) you can trivially wrap it up with `block_on` and move on with your life.
  - corethree 3y ago
    I could. But I could also write the whole thing in assembly or go. I want a language that does everything I want and that includes a clean async api. I think there's a hole here because what "I" described as what "I" want is what a lot of people want.
    - withoutboats3 3y ago
      You are commenting on a very long post in which I explained in detail how green threading wasn't compatible with Rust's lack of garbage collection. Your response is to just insist that you wish that wasn't the case - that you could have no garbage collection and user-space concurrency without any special syntax. Just repeating a demand in the face of an explanation as to why it isn't possible isn't going to get you far. I actually think what you want is green threading and garbage collection and the language I described at the end of my post, but you've sort of ideologically decided garbage collection is bad for whatever reason.
      - corethree 3y ago
        No I'm saying just do allocations and box under the hood for async await. Not for rust but for the ideal language people want but is missing. Rust obviously has a zero cost objective. I'm not directly talking about that.
- ReleaseCandidat 3y ago
  > Where can I find a language with no garbage collection, nice sum types and no over complicated async syntax? Austral: https://borretti.me/article/introducing-austral https://borretti.me/article/introducing-austral It doesn't have complicated async syntax, because it doesn't have it at all :) https://borretti.me/article/introducing-austral#fn:async https://borretti.me/article/introducing-austral#fn:async
  - corethree 3y ago
    I should add: that is also popular and easy to find a job for. I'm sure plenty of languages fit the bill, but will I find gainful employment with that language? Probably not.
alilleybrinker 3y ago
Agreed on the grandstanding! I can’t think of another topic area where the option space is extremely rich and full of trade-offs and the discussion space is so full of strong claims of there being one obvious and unquestionably best solution.

corethree 3y ago

The community needs a language that isn't so extreme that is opinionated on what is zero cost and what is not. Golang sort of fits this bill as it has an opinionated take on this, but overall from my pov it's a bad opinion. No sum types, no namespaces, garbage collection.... I feel it's still the only other language that fills this space that isn't so OOP. It's a bad solution and it's popular because it's the only solution. Anyway to get back to your point, I think this is why so many people complain. It's either go or rust and neither is ideal so one way to deal with the problem is attempting to shape rust into this ideal. Right? Where can I find a language with no garbage collection, nice sum types and no over complicated async syntax? Where? Nowhere. This is what people want.

Rusky 3y ago
You can just not write async code in Rust, no? There are a lot of Rust programmers that work this way, and it's fine because async is quite separable from the rest of the language. Even if you have to pull in a dependency that uses async (though if you are not doing async stuff yourself, why would you??) you can trivially wrap it up with `block_on` and move on with your life.
- corethree 3y ago
  I could. But I could also write the whole thing in assembly or go. I want a language that does everything I want and that includes a clean async api. I think there's a hole here because what "I" described as what "I" want is what a lot of people want.
  - withoutboats3 3y ago
    You are commenting on a very long post in which I explained in detail how green threading wasn't compatible with Rust's lack of garbage collection. Your response is to just insist that you wish that wasn't the case - that you could have no garbage collection and user-space concurrency without any special syntax. Just repeating a demand in the face of an explanation as to why it isn't possible isn't going to get you far. I actually think what you want is green threading and garbage collection and the language I described at the end of my post, but you've sort of ideologically decided garbage collection is bad for whatever reason.
    - corethree 3y ago
      No I'm saying just do allocations and box under the hood for async await. Not for rust but for the ideal language people want but is missing. Rust obviously has a zero cost objective. I'm not directly talking about that.
ReleaseCandidat 3y ago
> Where can I find a language with no garbage collection, nice sum types and no over complicated async syntax? Austral: https://borretti.me/article/introducing-austral https://borretti.me/article/introducing-austral It doesn't have complicated async syntax, because it doesn't have it at all :) https://borretti.me/article/introducing-austral#fn:async https://borretti.me/article/introducing-austral#fn:async
- corethree 3y ago
  I should add: that is also popular and easy to find a job for. I'm sure plenty of languages fit the bill, but will I find gainful employment with that language? Probably not.

alilleybrinker 3y ago

Agreed on the grandstanding! I can’t think of another topic area where the option space is extremely rich and full of trade-offs and the discussion space is so full of strong claims of there being one obvious and unquestionably best solution.