5 ms·

> By "no dependence on run times." I mean no async/await. It is an abomination in Rust Out of curiosity, what alternative would you have preferred to see, if a

> By "no dependence on run times." I mean no async/await. It is an abomination in Rust Out of curiosity, what alternative would you have preferred to see, if any?

worik 2y ago
Non blocking standard library functions I find it astounding that so many people think asynchronous programming means async/await Asyc/await is a way of letting programmers who do not want to learn how, do asynchronous programming. It has poisoned the well
- xedrac 2y ago
  I've been doing asynchronous programming for decades, and async/await is a notable improvement for many use cases. Event loop + callback hell, or condition variable/mutex/semaphore approaches are great in some cases, but they suck in others.
  - worik 2y ago
    > I've been doing asynchronous programming for decades, and async/await is a notable improvement for many use cases. I think that goes to taste. > Event loop + callback hell That was always due to indisciplined programming. Async/await offers up other hells. I think it makes some sense in memory managed systems. But in a system with static compile time management like Rust async/await forces all sorts of compromises. Mostly these fall on library authors, but it is its own hellscape. `Pin`? > great in some cases, but they suck in others That is a universal refrain for software systems!
- aw1621107 2y ago
  > Non blocking standard library functions What approach are you thinking of for the API of those functions, since async/await is not something you'd like to see?
  - mfenniak 2y ago
    I believe this is reference to Go's approach, where code can be written in a linear straightforward fashion with normal function calls, but, if they are syscalls then they become async automatically. I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.
    - aw1621107 2y ago
      I suppose that makes sense given OP's definition of "no dependence on run times", but I think I'd have to agree that that approach probably wouldn't work well for the niche Rust is trying to target.
    - worik 2y ago
      > I believe this is reference to Go's approach, I am unfamiliar with GO. I am thinking of the way the C library does it. > I don't think it's appropriate for the level of coding that Rust is targeting That would be low level system programming. In part
      - aw1621107 2y ago
        > I am thinking of the way the C library does it. What way is that? I didn't think the C standard library had any understanding of blocking/non-blocking.
        worik 2y ago
        O_NONBLOCK
        aw1621107 2y ago
        That's technically POSIX, not standard C, isn't it? But in any case, I'm pretty sure Rust has supported the nonblocking functionality you want for quite a while now (maybe since 1.1.0)? You'll need to piece it together yourself and use the libc crate since it's a platform-specific thing, but it doesn't seem too horrendous. Ultimately it comes down to the fact that the fundamental method for the std:io::Read is fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize>; which is perfectly compatible with non-blocking reads. For example, std::io::File implements Read and std::os::fd::FromRawFd, so if you can get a non-blocking file descriptor you should have non-blocking reads for files.
- dwattttt 2y ago
  I very much do not want to go back to the days of "read up to 4 bytes off the wire to see how big the next chunk is. Oh I only read 3 bytes? Guess I'd better save those 3 + the fact I need to read 1 more, then drop back out to the event loop"
  - worik 2y ago
    > I very much do not want to go back to the days of .... Not what I recommend. The C library does much better than that. In asynchronous programming you can only deal with the data you have, so you buffer it. I have not counted bytes like that - for the purposes of reading from a file, in decades.
    - dwattttt 2y ago
      But that's where non-blocking leads; it can't block until it reads all the bytes you asked for, that has to be handled somehow. A fancy C library could buffer the partial read for you rather than you needing to do it, and it could even maybe deal with turning your function into the state machine required to resume the function at the partial read. But then you look around and realise you've created another async/await.

> By "no dependence on run times." I mean no async/await. It is an abomination in Rust Out of curiosity, what alternative would you have preferred to see, if any?

worik 2y ago

Non blocking standard library functions I find it astounding that so many people think asynchronous programming means async/await Asyc/await is a way of letting programmers who do not want to learn how, do asynchronous programming. It has poisoned the well

xedrac 2y ago
I've been doing asynchronous programming for decades, and async/await is a notable improvement for many use cases. Event loop + callback hell, or condition variable/mutex/semaphore approaches are great in some cases, but they suck in others.
- worik 2y ago
  > I've been doing asynchronous programming for decades, and async/await is a notable improvement for many use cases. I think that goes to taste. > Event loop + callback hell That was always due to indisciplined programming. Async/await offers up other hells. I think it makes some sense in memory managed systems. But in a system with static compile time management like Rust async/await forces all sorts of compromises. Mostly these fall on library authors, but it is its own hellscape. `Pin`? > great in some cases, but they suck in others That is a universal refrain for software systems!
aw1621107 2y ago
> Non blocking standard library functions What approach are you thinking of for the API of those functions, since async/await is not something you'd like to see?
- mfenniak 2y ago
  I believe this is reference to Go's approach, where code can be written in a linear straightforward fashion with normal function calls, but, if they are syscalls then they become async automatically. I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.
  - aw1621107 2y ago
    I suppose that makes sense given OP's definition of "no dependence on run times", but I think I'd have to agree that that approach probably wouldn't work well for the niche Rust is trying to target.
  - worik 2y ago
    > I believe this is reference to Go's approach, I am unfamiliar with GO. I am thinking of the way the C library does it. > I don't think it's appropriate for the level of coding that Rust is targeting That would be low level system programming. In part
    - aw1621107 2y ago
      > I am thinking of the way the C library does it. What way is that? I didn't think the C standard library had any understanding of blocking/non-blocking.
      - worik 2y ago
        O_NONBLOCK
        aw1621107 2y ago
        That's technically POSIX, not standard C, isn't it? But in any case, I'm pretty sure Rust has supported the nonblocking functionality you want for quite a while now (maybe since 1.1.0)? You'll need to piece it together yourself and use the libc crate since it's a platform-specific thing, but it doesn't seem too horrendous. Ultimately it comes down to the fact that the fundamental method for the std:io::Read is fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize>; which is perfectly compatible with non-blocking reads. For example, std::io::File implements Read and std::os::fd::FromRawFd, so if you can get a non-blocking file descriptor you should have non-blocking reads for files.
dwattttt 2y ago
I very much do not want to go back to the days of "read up to 4 bytes off the wire to see how big the next chunk is. Oh I only read 3 bytes? Guess I'd better save those 3 + the fact I need to read 1 more, then drop back out to the event loop"
- worik 2y ago
  > I very much do not want to go back to the days of .... Not what I recommend. The C library does much better than that. In asynchronous programming you can only deal with the data you have, so you buffer it. I have not counted bytes like that - for the purposes of reading from a file, in decades.
  - dwattttt 2y ago
    But that's where non-blocking leads; it can't block until it reads all the bytes you asked for, that has to be handled somehow. A fancy C library could buffer the partial read for you rather than you needing to do it, and it could even maybe deal with turning your function into the state machine required to resume the function at the partial read. But then you look around and realise you've created another async/await.