I am sure that a Rust team member will be here soon to set the record straight, however, my take:

> Rust side there's things like mio for fast io but coroutine/light threads aren't really a focus afaik

IO and concurrency/parallelism models are a very difficult topic to really discuss and quantify performance around.

The highest-known-performance network server architecture revolves around edge-triggered epoll/kqueue (evented, async IO) and state machines (eschewing the stack entirely.)

pthreads (speaking exclusively about POSIX here - Windows threads are far heavier-weight than pthreads) suffer the cost of context switching due to large (by default - this can be configured) stack sizes.

This is one reason why languages like Go and Erlang have their own stack and lightweight process (greenthread) implementations.

For the record: Rust had green threading, and I believe it was removed due to the overhead relating to supporting it. The simple fact that you really cannot control or know when FFI calls will block (libc included) or not makes greenthreading tricky.

The trickier thing, IMO, relating to async IO is just the compatibility aspect:

- Golang/Erlang control compatibility by offering entire ecosystems built around their greenthread models.

  - Golang even goes as far as replacing the vast majority of libc and much of what you would want to call out to C for.

- Rust, being a systems language, cannot dictate "all code must use async IO and this specific reactor/event loop implementation," the stdlib is too small (by design), calls to libc are too pervasive.

With all of that being said:

- I personally believe Rust core should adopt a blessed async IO system (event loop, OS-level abstraction layers, basically mio) that all code could opt into using. - Additionally, it would be lovely if, on top of said system, compiler support for stackless coroutines (a la async/await) and a multithreaded reactor were implemented.

I love Rust, but I can't use it for network server related tasks until this part of the ecosystem is more developed and made more consistent.

mio is the de facto stdlib AIO implementation, but there's still a lot of fragmentation, and many libs still use the blocking networking builtins, rendering them incompatible.

I've been reading about Elixir recently, yes. Thanks for mentioning it, though. I'll have to look at it at some point, but since my code is primarily run-in-a-browser, I'm currently stuck with compile-to-JavaScript languages. I'm concerned that Elixir is too functional for my tastes (I find Haskell to be too pure (and slow) to be really usable for most tasks I work on, for instance), but I will give it a look at some point.

The entire point of writing in Go or Elixir would be to avoid needing to write an event based system in Rust (or C). Writing code as if it's imperative but getting the speed of an event-based system is what I'm looking for. Event-based systems are notoriously hard to reason about and debug.

You just can't be happy if someone else is using Go, can you.