4 ms·

I am too lazy to deal with Async at this time.

worik 2y ago
I do not understand how async/await got introduced into a language with no garbage collector. The mountains Rust has to move, in invisible magical ways, to get the tokio runtime to work without a garbage collector is deeply disturbing (`pin` anyone?) I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector? But what gets me most is that asynchronous programming is not hard (harder than it should be in Rust due to the absence of non-blocking file handles....) and async/await makes the easy things a bit easier, whilst making some difficult things very very difficult. The trade offs are all wrong, it is very popular and widely used. Reminds me of Microsoft in 1997
- gwbas1c 2y ago
  > I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector? Because a garbage collector does not have an invisible runtime: The memory model is tightly coupled with the garbage collector. This is not zero-cost. All garbage collection comes with some cost; although for many kinds of programming it's so "worth it" that we don't need to consider alternatives. As someone who's spent most of my career using garbage collected languages; I both appreciate the advantages that come with the tradeoffs of garbage collection; and the tradeoffs that come with Rust. Rust has no runtime memory management overhead, and no complicated framework to ship. I still personally don't understand "why" async Rust is so hard. I struggled trying to use it, but at the time I was such a Rust novice that I "didn't know what I didn't know." Yes, async Rust would be easier if the language was garbage collected; but that defeats the point of Rust.
  - gwbas1c 2y ago
    Just to follow up a bit: Rust excels at things like command-line utilities, or high-performance libraries (that don't require you to suck in a whole framework.) In these cases, the case for "async" isn't strong, because chances are there isn't enough concurrent IO to for async vs threaded to make a difference. If you're making a web application, chances are you're hosting it yourself. Thus, you don't have to "ship" your software and compel your users to load up whatever framework(s) you choose. IE, you can choose to use C# or Node.js, and decide that it's worth your time to spend more on hosting.
- iknowstuff 2y ago
  Jesus fucking christ not this again. https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/ There are entire articles explaining precisely why. Your lack of knowledge contributes very little to an article about a framework.
  - worik 2y ago
    That article assumes that there needed to be language level support for asynchronous programming, beyond non-blocking operations. My point is that that is not true. If you want to use the blocking paradigms for asynchronous programming, then yes, there does need to be some magic added to make it work. If, however, you are comfortable with asynchronous programming (and it is not hard) then all you need are the non-blocking operations.
    - iknowstuff 2y ago
      Its massive adoption proves you wrong. You’re welcome to use epoll/kqueue manually if you want. Doesnt mean there’s no need for the ecosystem.
      - worik 2y ago
        > Its massive adoption proves you wrong No! * Window NT in 1991. Displaced much better systems, on mass * Node.js (my job) is simply dreadful. Mass adoption there too * It took until 2015 to get half way to a replacement for C for real time systems. C is incredibly prone to failure - and it still has mass adoption. (Very tricky that one) Popularity is a very bad metric for choosing computer systems. (Unless you are looking for a job - see above for Node.js)
- sunshowers 2y ago
  Heterogeneous selects are just not possible to do in a cross-platform manner, without async/await. Rust is one of the very few environments which lets you do them in a reasonable manner -- the other alternatives are a nest of threads or a hand-written message loop-based state machine, both of which don't scale well as complexity goes up.
  - worik 2y ago
    https://crates.io/crates/mio https://crates.io/crates/mio
    - sunshowers 2y ago
      Right, which (if you use it without Tokio) means you're managing a message loop by hand. Doesn't quite scale up to state machines with 50+ states.
      - worik 2y ago
        > Doesn't quite scale up to state machines with 50+ states. It is a lot of lines of code, but simple. It is the easy thing.

I do not understand how async/await got introduced into a language with no garbage collector. The mountains Rust has to move, in invisible magical ways, to get the tokio runtime to work without a garbage collector is deeply disturbing (`pin` anyone?) I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector? But what gets me most is that asynchronous programming is not hard (harder than it should be in Rust due to the absence of non-blocking file handles....) and async/await makes the easy things a bit easier, whilst making some difficult things very very difficult. The trade offs are all wrong, it is very popular and widely used. Reminds me of Microsoft in 1997

gwbas1c 2y ago
> I do not understand that if you are happy to have an invisible runtime run your programme why you do not want a garbage collector? Because a garbage collector does not have an invisible runtime: The memory model is tightly coupled with the garbage collector. This is not zero-cost. All garbage collection comes with some cost; although for many kinds of programming it's so "worth it" that we don't need to consider alternatives. As someone who's spent most of my career using garbage collected languages; I both appreciate the advantages that come with the tradeoffs of garbage collection; and the tradeoffs that come with Rust. Rust has no runtime memory management overhead, and no complicated framework to ship. I still personally don't understand "why" async Rust is so hard. I struggled trying to use it, but at the time I was such a Rust novice that I "didn't know what I didn't know." Yes, async Rust would be easier if the language was garbage collected; but that defeats the point of Rust.
- gwbas1c 2y ago
  Just to follow up a bit: Rust excels at things like command-line utilities, or high-performance libraries (that don't require you to suck in a whole framework.) In these cases, the case for "async" isn't strong, because chances are there isn't enough concurrent IO to for async vs threaded to make a difference. If you're making a web application, chances are you're hosting it yourself. Thus, you don't have to "ship" your software and compel your users to load up whatever framework(s) you choose. IE, you can choose to use C# or Node.js, and decide that it's worth your time to spend more on hosting.
iknowstuff 2y ago
Jesus fucking christ not this again. https://without.boats/blog/why-async-rust/ https://without.boats/blog/why-async-rust/ There are entire articles explaining precisely why. Your lack of knowledge contributes very little to an article about a framework.
- worik 2y ago
  That article assumes that there needed to be language level support for asynchronous programming, beyond non-blocking operations. My point is that that is not true. If you want to use the blocking paradigms for asynchronous programming, then yes, there does need to be some magic added to make it work. If, however, you are comfortable with asynchronous programming (and it is not hard) then all you need are the non-blocking operations.
  - iknowstuff 2y ago
    Its massive adoption proves you wrong. You’re welcome to use epoll/kqueue manually if you want. Doesnt mean there’s no need for the ecosystem.
    - worik 2y ago
      > Its massive adoption proves you wrong No! * Window NT in 1991. Displaced much better systems, on mass * Node.js (my job) is simply dreadful. Mass adoption there too * It took until 2015 to get half way to a replacement for C for real time systems. C is incredibly prone to failure - and it still has mass adoption. (Very tricky that one) Popularity is a very bad metric for choosing computer systems. (Unless you are looking for a job - see above for Node.js)
sunshowers 2y ago
Heterogeneous selects are just not possible to do in a cross-platform manner, without async/await. Rust is one of the very few environments which lets you do them in a reasonable manner -- the other alternatives are a nest of threads or a hand-written message loop-based state machine, both of which don't scale well as complexity goes up.
- worik 2y ago
  https://crates.io/crates/mio https://crates.io/crates/mio
  - sunshowers 2y ago
    Right, which (if you use it without Tokio) means you're managing a message loop by hand. Doesn't quite scale up to state machines with 50+ states.
    - worik 2y ago
      > Doesn't quite scale up to state machines with 50+ states. It is a lot of lines of code, but simple. It is the easy thing.