Edit: No that's not exactly true http://stackoverflow.com/questions/7005759/erlang-on-multico... But they do spawn a processes for each core.

Each thread runs a scheduler and the many Erlang processes are balanced between the schedulers. There is still only one OS process though.

http://erlang.2086793.n4.nabble.com/Some-facts-about-Erlang-...

In any case the distinction between "multiple processes" and "multiple threads" here is fairly minimal, at least on Linux or OS X. As far as the kernel is concerned, they're the same object (Linux calls them threads; Mach calls them tasks). It's just that sometimes, groups of these things share pointers to things like memory map or file descriptor table, and sometimes they have their own pointers. There isn't a whole lot of difference, either at the language level or the kernel level, between running multiple processes from the same executable image that map a shared heap versus just running multiple threads.

I could see Rust's ownership and multithreading amenability being extremely useful at this level, but admittedly I don't know enough.

(And yes, Rust's threading safety applies equally well to that. It doesn't care about the details of how code is running concurrently/in parallel, just that it could be.)