3 ms·

Can someone explain me why that is? It just seems like it is the dumbest thing in the world to me. The OS may be good at scheduling, but why not have a built in

by tormeh 12y ago

Can someone explain me why that is? It just seems like it is the dumbest thing in the world to me. The OS may be good at scheduling, but why not have a built in library providing you with an alternative? Native threads are usually really slow to start and stop, because they have high memory use and even modern OSs can only handle on the order of 10000 of them. When I saw this decision my first reaction was "Well, that was a promising language. Shame about that." I can't be the only one...

steveklabnik 12y ago
A systems programming language without access to a systems feature isn't much of a systems language. Also, it doesn't _preclude_ green threads. As others have mentioned, Rust is low-level enough that all of this is a library issue, not a language issue. You can write whatever concurrency primitives you need, and they'll be no less privileged as the ones the standard library gives you.
- tormeh 12y ago
  Well, yes, but anything that's merely a convenience and not in the standard library won't see much use, as I've understood programmer nature.
  - steveklabnik 12y ago
    Rust's standard library will be much less privileged than in other languages, due to Cargo existing from the start. It's going to be much more slim than most, we've already pulled lots of things out into their own packages. Also, given that only part of the standard library will be stable at 1.0.
Jweb_Guru 12y ago
This is actually not the case on Linux. Starting up a thread is really fast. One of Rust's contributors found that it was just as fast at spawning threads as Rust was at spawning green threads when both were pinned to one core. Additionally, for a variety of reasons Rust's tasks were not smaller than OS threads, because they need to be bigger for a lot of things (calling into C, for example) and segmented stacks were found to be much too slow. Go gets around these problems by allocating a new stack when the current one runs out of space, but doing that properly requires being able to trace all the pointers into the stack to figure out where to transfer them--in other words, it requires a garbage collector :) So that solution wasn't really viable for Rust. Finally, having to support both concurrency models required Rust to make significant sacrifices in its libraries, in both complexity and performance. Go was able to make the decision to focus entirely on green threading, but Rust did not take that approach, so it was stuck in a "worst of both worlds" situation. It is possible that there is a better solution that avoids all these problems, but it will have to be found outside the main Rust tree.

by tormeh 12y ago

steveklabnik 12y ago

A systems programming language without access to a systems feature isn't much of a systems language. Also, it doesn't _preclude_ green threads. As others have mentioned, Rust is low-level enough that all of this is a library issue, not a language issue. You can write whatever concurrency primitives you need, and they'll be no less privileged as the ones the standard library gives you.

tormeh 12y ago
Well, yes, but anything that's merely a convenience and not in the standard library won't see much use, as I've understood programmer nature.
- steveklabnik 12y ago
  Rust's standard library will be much less privileged than in other languages, due to Cargo existing from the start. It's going to be much more slim than most, we've already pulled lots of things out into their own packages. Also, given that only part of the standard library will be stable at 1.0.

Jweb_Guru 12y ago

This is actually not the case on Linux. Starting up a thread is really fast. One of Rust's contributors found that it was just as fast at spawning threads as Rust was at spawning green threads when both were pinned to one core. Additionally, for a variety of reasons Rust's tasks were not smaller than OS threads, because they need to be bigger for a lot of things (calling into C, for example) and segmented stacks were found to be much too slow. Go gets around these problems by allocating a new stack when the current one runs out of space, but doing that properly requires being able to trace all the pointers into the stack to figure out where to transfer them--in other words, it requires a garbage collector :) So that solution wasn't really viable for Rust. Finally, having to support both concurrency models required Rust to make significant sacrifices in its libraries, in both complexity and performance. Go was able to make the decision to focus entirely on green threading, but Rust did not take that approach, so it was stuck in a "worst of both worlds" situation. It is possible that there is a better solution that avoids all these problems, but it will have to be found outside the main Rust tree.