Go supports timeouts on network & file read/write ops, which can be used to interrupt them.
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.
https://github.com/rust-lang/rust/issues/11214
To support user intervention when a task takes longer than expected, all blocking syscalls should be interruptible.
std::fs::File's impl of std::io::Read:
https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...
-> https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...
-> https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...
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.
https://github.com/rust-lang/rust/blob/7fc048f0712ba515ca11f...
Have they taken out the EINTR retries which were added for the issue I linked?
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...