And
> everyone always reaches to the most clever way to do things.
Yes oh yes
Rust was a brilliant idea spoilt by too much cleverness
I'm hoping for Rust II. A smaller language, with a bigger standard library and no dependence on run times.
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?
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
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!
What approach are you thinking of for the API of those functions, since async/await is not something you'd like to see?
I don't think it's appropriate for the level of coding that Rust is targeting... But... It would be nice.
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
What way is that? I didn't think the C standard library had any understanding of blocking/non-blocking.
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>;
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.
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.