It seems that the author places a lot of emphasis on the maturity and future prospects of various libraries. I'm surprised that Rust was so quickly dismissed as tokio seems to have a bright future ahead of it.
What I do think is a fair point is Rust's learning curve. With that in mind I would like to suggest a third alternative: Nim.
Support for epoll/kqueue/IOCP has been in Nim's standard library for a while now and is already very mature. The learning curve is probably somewhere between Rust and Go. In addition Nim also offers a GC that is predictable and controllable.
Given how demanding ESR is with regards to 10+ years stability, Nim hasn't even reached 1.0 yet. I love Nim and your contribution to the Nim ecosystem, but yeah, convincing ESR with 0.16.0 isn't happening.
Nim could be ideal for applications like NTP that require speed, portability and low memory footprint.
I wonder if the ease of development already outweighs the efforts required to keep up with the language growth pains and writing wrappers for system libraries where needed.
tokio is far from mature and its claims of stability are even less so. I can't think of many Rust crates that I'd seriously put in the "this seems actually stable and mature" bucket as yet. That's in part because Rust itself is only recently stable (and given how recently it's pretty generous to call it stable).
What I do think is a fair point is Rust's learning curve. With that in mind I would like to suggest a third alternative: Nim.
Support for epoll/kqueue/IOCP has been in Nim's standard library for a while now and is already very mature. The learning curve is probably somewhere between Rust and Go. In addition Nim also offers a GC that is predictable and controllable.