Rust may eventually get async/await syntax that works with futures so coroutine-based programming would be easy to do, regardless of whether or not it is backed by an event loop like tokio or something else.

I'm not sure I get your point here, from other comments it seems like you're annoyed that Rust didn't choose a solution, and when tokio (which is the "chosen" solution for server side async stuff) is talked about you wish it had chosen a different one.

As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming.

> As I mentioned in my other comment I'm also not sure what you mean by "concurrency primitives" here, from your mention of server-side programming it would appear that you want something that handles async I/O, but this comment seems to indicate otherwise, and Rust does have pretty nice primitives (in the stdlib, and in rayon/crossbeam) for general parallel programming.

Since he mention Go and Erlang, I think what the gp just wishes Rust had a built-in solution for M:N threading.

Whether M:N threading is nicer than async APIs is highly subjective though. (I'm talking about ergonomics here. I think it's widely accepted that async is more efficient when performance really matters)

> I think what the gp just wishes Rust had a built-in solution for M:N threading.

Yeah, but then they say that they doesn't want concurrency to be based on async io primitives, which is exactly what Go does IIRC.

Both Go and Erlang are based on blocking, synchronous I/O primitives combined with asynchronous communication between the green threads that use them. It's a lot easier to reason about than event-based I/O.

> which is exactly what Go does IIRC.

Under the hood, I guess yes. But in Go, the developer always use blocking API and the runtime does the magic with the async stuff. Some people find it easier to reason about code written this way.

My point is that i wished rust made the choice to favor actor style concurrency officially. Which means autonomous entities communicating by message passing, having a single "run loop" ( thread, coroutine whatever), and encapsulating a state.

I mentionned async io but i should have added "+ event loop", because they can be used for different things indeed.

Now maybe the rust team could officialy endorse one programming model for the server side, but keep the language itself agnostic, so that other people could try and do different things in the future. But i don't think leaving it all to the community to decide is good for the very beginning. You need everyone to go in the same direction because there isn't enough talented people to run multiple races at the same time ( but honestly i don't have that,much experience running communities, so it's just my feeling).

> My point is that i wished rust made the choice to favor actor style concurrency officially.

I think you're asking Rust to be a high-level language like Erlang or Go, and not a near-the-metal systems programming language that may (someday) have an "official" story about using actors for people writing servers.

Rust's threads are raw OS-level threads, because using green threads by default (or as an option) imposed serious overhead elsewhere:

http://stackoverflow.com/questions/29428318/why-did-rust-rem... https://github.com/rust-lang/rfcs/blob/0806be4f282144cfcd55b... https://aturon.github.io/blog/2016/08/11/futures/

From the third link:

> The problem is that green threads were at odds with Rust’s ambitions to be a true C replacement, with no imposed runtime system or FFI costs: we were unable to find an implementation strategy that didn’t impose serious global costs.

tokio+mio is "async io + event loop". I think tokio-fiber tries to build coroutines on top of it.

This is (or, will be) the "officially endorsed" async model for the server side. All the libraries you'll be using *hyper, etc) are going to be integrated with it. It's not yet finished, but when it is it will be.

In the future if we get async/await that would be an even more ergonomic thing that can be used with futures (and hence, tokio), but most of the machinery is already planned for tokio itself.

I believe the idea is that tokio, because of its zero-cost abstractions will be able to be efficiently be the foundation of those styles.

Check out https://github.com/dpc/tokio-fiber/ for co-routines being re-envisioned on tokio, and https://github.com/rust-lang/rfcs/issues/613 acknowledges that the actor story is still a work-in-progress.

I have seen no indication that either coroutines or futures will be less ergonomic or performant due to being built on top of tokio's futures.

This whole discussion regarding concurrency/parallelism stacks made me think that there's probably a good blog post to write:

Start with low-level OS system calls and show what pieces one needs to write to reach higher level abstractions like futures, coroutines , async / await, nodejs style event loop, or full blown actors.

That would also make for a nice roadmap to whoever would like to build OTP or Akka style framework in Rust.