I think the problem is partly that many programming languages make it difficult to propagate cancellation correctly and idiomatically. So people end up adding timeouts to individual network requests instead of to the operation as a whole.
>Go, Rust, and Zig make it impossible to interrupt most blocking syscalls, because they automatically retry on EINTR.
This is not true of Rust. Some of the convenience wrappers (std::io::Read::read_exact, etc) on top of the basic primitives (std::io::Read::read, etc) do retry for you (and explicitly document it), but not "Rust" as a whole. The primitives map one-to-one to calls of read/write/sendto/recvfrom and bubble up ErrorKind::Interrupted to the caller just fine.
The Rust filesystem API works (or once did) as I described. This can render an application unusable when trying a network filesystem or storage device that's unavailable.
Again, as I said, it corresponds one-to-one with a call to the underlying read API. The retries for ErrorKind::Interrupted are done by higher abstractions like std::io::Read::read_exact, and they explicitly document that they do this.
Go only recently started handling -EINTR correctly (retrying the operation) though I do agree that this should've only been done in the higher-level wrappers. The "os" package shouldn't be doing retries IMHO.
Pre-1.14 -EINTRs were quite rare in "normal" Go programs so the stdlib basically ignored them, but 1.14 introduced preemption which resulted in many more -EINTRs and quite a few Go programs were broken as a result. So in many ways this behaviour was necessary to un-break backwards compatibility. If Go had made the interruption semantics -- which had existed for at least a decade before Go came about -- clearer from the outset then maybe this whole business could've been avoided.
This is symptomatic of the reasons why container runtimes (at least, those written in Go) have historically been vary wary of Go updates. Several years ago, each Go release would change some minor semantics of the Go runtime and cause breakages...
