Well, what domains is Rust targeting? Rust still isn't a good fit for embedded/kernel stuff without allocators and OOM handling (not to mention every architecture not targeted by LLVM).
That leaves userland applications, and how many applications don't need concurrent IO?
I'm definitely being impatient, and I'm sorry for that. It's just frustrating to see only one core member working on it.
Many user-space applications don't do heavy network work, which is where concurrent IO is most necessary. E.g. games or a scientific simulation, even web-browsers don't need of concurrent IO (they're not trying to juggle thousands of connections).
Which doesn't, correct me if I'm wrong, provide a stable allocator API or OOM handling yet.
>E.g. games
When your client pings 400 servers, how is it doing that? How is the game server implemented?
>a scientific simulation
That runs on one machine, and doesn't do a lot of disk IO? (concurrent file IO matters too).
>even web-browsers
Open the Chrome dev tools "network" tab, and then open Gmail. How many requests did it make?
Again, concurrent IO is important.
There are cross-cutting concerns that apply to everything (including concurrent IO libraries) that development work is focusing on. Rust doesn't need to eat Go's/Scala's/Clojure's... lunch 3 months after it was released, taking a year or two to settle in and branch out seems fine to me.