5 ms·
What they are getting at is that the Go designers are stubborn and the Rust designers are open-minded... but they don't want to just come out and say that. For
by bsdetector 11y ago
What they are getting at is that the Go designers are stubborn and the Rust designers are open-minded... but they don't want to just come out and say that.
For instance both had green threads. Rust designers ran into all the problems with them like interop with anything else and interrupts and fairness, so like everybody else that did M:N threading they threw up their hands and said "well it looked like a good idea at first" and removed it. Go designers literally called it a "rabbit hole" and followed it down to whatever crazy lands it lead to, because they promised people green threads so they had to keep it.
- Manishearth 11y agoTrue. For the record I like the Rust model a lot more (obviously, as a contributor, I should); but what I'm saying is that there's a tradeoff and both have their good parts. The moment you're open to some community decision making, you're expected to be open to all of it -- Go doesn't get much flak from the community for unilateral decisionmaking. I bet it would if it started to allow some community consensus on some decisions. And like I said, the "let the community decide everything" model probably wouldn't work for Go, so unilateral it is :)
- NateDad 11y agoThat's very sad for Rust, because Go's goroutines are amazingly awesome.
- pcwalton 11y agoI firmly believe that moving away from M:N threading was the right decision for Rust. Even if nothing else, the fact that Rust FFI performance is thousands of times faster than cgo alone justifies the decision. There are numerous other reasons (fairness, I/O performance, performance of synchronization primitives, implementation complexity) why just using the OS scheduling is superior for a systems language. The primary benefit of M:N scheduling—fast thread spawning due to small initial stack sizes—requires GC, which Rust doesn't have, and arguably has little to do with M:N scheduling in the first place, given that thread stacks are configurable in the syscall.
- NateDad 11y agoI believe you know what you're talking about, and so are right about what's best (or really, even possible) in rust, but I can still be sad that there's not some magic way to have my cake and eat it too.
- SamReidHughes 11y agoHow does having small initial stack sizes give you fast thread spawning?
- pcwalton 11y agoBecause you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
- SamReidHughes 11y agoBut you can allocate large stacks efficiently too. Is this something specific to how GC works? Edit: Is it about having stacks smaller than a page, maybe not aligned to 4K and not fighting for the same cache lines?
- pcwalton 11y agoIn general mallocs allocate small blocks a lot faster than they allocate large blocks, because small blocks qualify for free list binning and the OS kernel doesn't need to serve you as many pages. (It wasn't obvious to me either that this was the case, but try it and see for yourself!) :)
- SamReidHughes 11y agoAt RethinkDB we managed our own free lists for stacks for this reason. One funny problem with the first implementation was that a stack could be born on one posix thread and die on another -- and certain threads would accumulate all the stacks, while the others would keep allocating them fresh.
- Manishearth 11y agoI'm pretty certain green threading can be designed as a library. However, the choices made by that library need not affect the language as a whole anymore.
- Jweb_Guru 11y agoNot easily--it has to be able to hook in at the linker level in order to deal with thread local storage properly.