I'm surprised at the paragraph about rust having erlang style actor based parallellism... From what i've read, parallel programming was still heavily a work in design in Rust ( had a very recent discussion on using rust for http server side coding on HN whith people confirming this to me).
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 ?
It sounds like you're actually talking about non-blocking and asynchronous IO, rather than parallel programming. It is definitely true that the former is helpful for the latter, but not everyone is using parallelism/concurrency for IO tasks.
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:
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).
Ok. I'm not a language designer so correct if i'm wrong, but doing anything remotely looking like actors implies being able to do m:n threading in some way, which rust decided not to do recently. Correct ?
I am not clear that "Actors" directly implies M:N threading. Rust's spawn() makes a 1:1 thread, but you still talk between threads with channels, and you can't get shared memory without going through an Arc<Mutex<T>> or something similar.
> 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.
Not really. You can do actor model with 1:N or 1:1 threading. With 1:N you get actor-model concurrency without native-thread overhead per actor, but no parallelism; with 1:1 you get parallelism but you have native thread overhead for each actor. With M:N, you can limit your native thread overhead to whatever is useful given available hardware, while scaling out to as many actors as 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.
From my (admittedly super ignorant position) it felt very similar - message passing, spawn, etc. The primitives felt very similar. I'm sure they differ hugely in details ;)
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 ?