Earlier quoted context omitted.
On the flip side, though, those assumptions are also what lets a runtime actually do things for you. In the limit, a runtime that assumes nothing is simply machine language. Even C has a runtime, whose assumptions can be violated quite thoroughly by other languages. The less the language actually specifies, the more likely you are to encounter the situation where two Rust libraries can't work together because they ac…
This strikes me a pragmatic decision driven by wanting to reduce complexity and be interoperable with 3rd party libraries (mostly C code). If you read my other comment here, I outlined the problems I ran into with the N:M threading model (although mostly in C land). It strikes me as Rust ran into the same issues. I'm beginning to think that you can't make N:M well unless you take the approach that language X itself i…
Erlang's stance is probably irrelevant to anyone in the Go/Rust/C/C++ etc community; it does so many things differently that its experiences are unlikely to be useful. I'm pretty sure it's M:N, but, for instance, it also trivially has a NOT-stop-the-world GC, which is something that not many languages can say. Not only that it isn't "stop the world" but that it's also fairly trivially so. It doesn't have synchronization problems because it basically doesn't have synchronization. (In the OS sense. Of course your user code may have various sync concerns, but there's no OS-level race conditions, or memory race conditions, etc.) It pays for these characteristics, but also reaps various benefits.
(It's a pity that I don't know of any great single chunk of documentation on the Erlang VM I can point to; links solicited. It's such a different beast. Someone interested in learning about how it's different without necessarily learning Erlang would probably better just studying the VM itself.)
P.S.: Yo, 'sup.