Further commentary:

> When Rust was originally announced, the team had ambitions to pursue the multi-core MacGuffin with a green-threaded actor model, but they found out that it’s very hard to do green threads with native code compilation.

It's easy to do if you're willing to define certain synchronization points (such as I/O). IIRC, Rust abandoned Green threads because of a few reasons:

1. It doesn't play well with FFI. This is particularly true with segmented stacks, but Rust abandoned those before it abandoned green threading. With regular OS-provided stacks, FFI is a problem because the FFI call can't yield to the green scheduler.
2. It has an unavoidable performance problem even for code that doesn't use it. The existence of green threading means the entire runtime needs to be abstracted over a threading and I/O interface. This is a lot of complexity, and requires the use of dynamic dispatch for a lot of things that would otherwise be static dispatch. Rust originally switched to native as the default threading model but kept green threading as an option for a while, but this violates the concept of you-don't-pay-for-what-you-don't-use, especially since most people weren't even using green threading anymore.
3. It also made implementing some things very awkward. For example, because of the abstract notion of a runtime, you couldn't really implement selection over multiple file descriptors very well. Things like that must be handled by the runtime library or not at all, because for native threading you'd want to use select() (or kqueue or epoll) but for green threading the green threading library needs to deal with that. In Go, the standard solution there was to spawn multiple green threads that each block on one fd and communicate using channels (because the runtime can then collect all the blocked fds into a single select/kqueue/epoll), but that's unwanted overhead, and is especially not very good when you're not using the green threading.
4. Green threads encourage the use of lots of short-lived threads that have very shallow stacks. Rust abandoned segmented stacks with the understanding that the OS-provided virtual memory support was good enough that it didn't matter if every thread got an 8MB stack as it would allocate pages on-demand. But a 4k page for every green thread can be a lot of overhead if you're using thousands of green threads. You can of course explicitly request a smaller stack, but that's tricky to get right (if you request too little you explode). There was a lot of thought given to trying to statically determine how much stack space a given function call required (which is not always possible, and is especially tricky if there's any recursion) to deal with this, but that's a very hard problem.

Ultimately, it was determined that green threads simply weren't worth all the costs. The OS is pretty good about dealing with lots of threads, and arguably it's actually better than the green threading library is about scheduling them all. Green threading makes some sense if you want to spawn 10,000 simultaneous threads, but in nearly all real-world workloads it's just not really worth it.

> Rust has taken up a different challenge: eliminating crashes from otherwise traditional, “boring” multi-threaded programs. In the sense that Rust has abandoned its original vision in favor of pursuing more modest and achievable goals*

I find this an odd thing to say. Statically eliminating crashes (and data races) without a garbage collector or any performance penalty is actually significantly more interesting than actors. Rust did not decide to pursue the more modest "boring" goal, it redoubled its focus on pursuing the very hard (but achievable) and very important goal of solving the problem of memory/data safety in multithreaded programs. This aspect of Rust is what most excited me when I first got involved 2 years ago and what still excites me to this day and makes me wish I could use Rust in my day job.

> For the record, the Nim language manages to get this right, and the Rust folks might look to it for inspiration.

I've heard of Nim before but haven't actually looked at it. Does it attempt to solve memory/data race safety at compile-time like Rust does?

> It is also worth noting that processing non-overlapping slices in parallel is destined to come into mortal conflict with The Iterator, which is by its nature sequential

I don't think this is true. You can build an Iterator that yields non-overlapping mutable slices, and then you can process them in parallel. The iterator is sequential, yes, but you can call it multiple times and hand the resulting references to your parallel computations (as opposed to handing the iterator itself over, which doesn't work because you'd be sharing mutable state without a lock and Rust does not allow you to write that code).

Although it's worth noting that at the moment you can't do fork-join concurrency (so you can't share mutable slices with parallel computations like that unless you cheat with `unsafe`). There's `thread::scoped()` but it's marked as unstable (so you can't use it from Beta or from tomorrow's Stable 1.0) because it has a serious safety issue, and the proposed replacements are still being worked on.