Erlang will use multiple OS threads if you start it with '-smp enabled'. Otherwise it would be limited to a single 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-...

Yeah, that's well-suited to Rust's design (although Rust didn't ship with libgreen, the requirements of libgreen influenced the type system, and you can do a similar thing with a third-party library).

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.

How do you run code on multiple cores? (What's your kernel in this case, if it's non-POSIX?)

Send some kind of very-low-level interrupt, pointing each core at code to run, I am guessing?

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

Isn't that exactly what a thread is? Well, threads generally have some management by the OS to allow more threads than CPU/share tasks evenly, but at their core, they allow you to give each core some code to run on.

(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.)