In my opinion they tried hard enough. Here are the links to the discussions of that time if you are into that kind of thing: https://mail.mozilla.org/pipermail

In my opinion they tried hard enough. Here are the links to the discussions of that time if you are into that kind of thing: https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html https://mail.mozilla.org/pipermail/rust-dev/2013-November/00... https://github.com/rust-lang/rfcs/blob/master/text/0230-remove-runtime.md https://github.com/rust-lang/rfcs/blob/master/text/0230-remo... It is clear that they really wanted to make green threading work, but in the end it proved incompatible with other goals of the language. The main problem as I understand it is with the stack: you can't make the stack big from the beginning (or your threads wouldn't be lightweight anymore) so you need to grow it dynamically. If you grow it by adding new segments to the linked list, you get the "stack thrashing"/"hot split" problem: if you are unlucky and have to allocate/deallocate a segment in a tight loop the performance suffers horribly. Go solved the problem by switching to contiguous relocatable stacks: if there is not enough space in the stack, a bigger contiguous chunk of memory is allocated and old contents of the stack are copied there (a-la C++ vector). Now there is a problem with references to the stack-allocated variables - they become invalid. In go this problem is solvable because it is a managed garbage-collected language so they can simply rewrite all the references to point to the new locations but in rust it is infeasible.