golang goroutine let me built a standalone binary with embedded https server and websocket support. Would Rust be able to do that even at 1.0 release without relying on low-level C library wrappers ?
In any case, Rust 1.0 is not aiming to be feature complete in language or library, it is just the point of guaranteed backwards compatibility and additions and improvements will continue. See:
- http://blog.rust-lang.org/2014/09/15/Rust-1.0.html
- http://blog.rust-lang.org/2014/10/30/Stability.html
The Rust standard library is not aiming to have async IO at 1.0, but external libraries have exactly the same low-level power as the standard library, so this functionality can be written externally, e.g. mio[0], and the Cargo package manager makes it super-easy to use them in your own applications (with reproducible builds, so no risk of upstream changes accidentally breaking the build).
Lastly, are you saying "(low-level C library) wrappers" or "low-level (C library wrappers)". The former is exactly what Rust will have, it has highly efficient FFI (a Rust -> C function call is the same as C -> C function call) and so can bind to the high-performance libraries other have written without any overhead. However, there's no reason that people can't build a nice and high-level API above the direct bindings though (this is exactly what happens, e.g. the game-development community has quite a few nice-to-use libraries[1] that are thin layers above the low-level C functionality).
[0]: https://github.com/carllerche/mio
[1]: https://github.com/rust-lang/rust/wiki/Computer-Graphics-and...
That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.
OTOH, M:N and 1:N both require you to do more to handle actors in the runtime, which potentially adds overhead to everything, M:N may not always be a win compared to 1:1.
> which rust decided not to do recently.
It's more subtle than this. Rust's I/O libraries are being re-done to remove the M:N stuff, yes, but Rust is low enough that I/O is just a library; anyone can implement alternate I/O stuff, it's not privileged other than coming with Rust. See mio as an example of an in-progress alternative.
(We also used to say "Erlang-style" in our marketing, but eventually removed it)