There already exist many affine-typed languages with fewer features than Rust. When you phrase it like "Rust but with weaker type safety and higher-overhead abstractions" one might see why this premise fails to gain much traction, though.
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"
> 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.
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.
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.
> 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`?
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.
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.
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
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.
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