> It's purely to avoid making OS threads wait on I/O in a concurrent application
This isn't true. That is, this is an important part of it, but that's not the only part. Thread APIs don't support things like cancellation natively, and async/await lets you write state machines in a way that doesn't look like a state machine.
> If OS threads were cheap enough to just spawn one for each request, this wouldn't be a thing.
These are both advantages regardless of the overhead of spawning OS threads.
> So now I'm wondering, if Golang and now Java can task-switch without the user having to tell it when, is there any point of doing it explicitly like in JS or Rust?
Yes. I actually gave two talks on this a while back, there's transcriptions on these pages:
Thanks for the links, Steve, good to hear from someone on the Rust team. Somehow I automatically assumed Rust's executors sorta acted like a runtime, but now that you mention it, no reason they have to intercept syscalls. Anyway, I'm watching the rest of those videos now.
And yeah, there's always that extra step of handling thread cancellation yourself. I probably shouldn't have said it's purely about cooperative multitasking, but the docs on this (e.g. Microsoft's C# guide) still obscure these points a lot of the time.
This isn't true. That is, this is an important part of it, but that's not the only part. Thread APIs don't support things like cancellation natively, and async/await lets you write state machines in a way that doesn't look like a state machine.
> If OS threads were cheap enough to just spawn one for each request, this wouldn't be a thing.
These are both advantages regardless of the overhead of spawning OS threads.
> So now I'm wondering, if Golang and now Java can task-switch without the user having to tell it when, is there any point of doing it explicitly like in JS or Rust?
Yes. I actually gave two talks on this a while back, there's transcriptions on these pages:
* https://www.infoq.com/presentations/rust-2019/
* https://www.infoq.com/presentations/rust-async-await/
The first one is more of what you're asking about, and the second one is how Rust's design here works.
One short way to answer the question though, is about this part:
> because the runtime automatically decides what is blocking
Yes, in Rust specifically, there is no runtime, and so you cannot make these guarantees.
I hope the first link answers things more thoroughly than that, but that's one simple way into thinking about this.