Re:Why We Use Go
by bsdetector on Wednesday May 27, 2015 @12:37AM
(#9609365)
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.
Re:Why We Use Go
by Manishearth on Wednesday May 27, 2015 @12:44AM
(#9609390)
True. 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 :)
That's very sad for Rust, because Go's goroutines are amazingly awesome.
I 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.
I 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.
Re:Why We Use Go
by SamReidHughes on Thursday May 28, 2015 @11:03PM
(#9622466)
How does having small initial stack sizes give you fast thread spawning?
Because you can pull the stack off the malloc free list bin, or even bump allocate it in a nursery.
Re:Why We Use Go
by SamReidHughes on Thursday May 28, 2015 @11:53PM
(#9622579)
But 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?
In 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!) :)
Re:Why We Use Go
by SamReidHughes on Friday May 29, 2015 @12:25AM
(#9622649)
At 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.
Yeah, caching works OK when your total thread count is relatively constant, but most thread spawning benchmarks do things like spawn 100000 threads, synchronize, and then shut them all down, in which case the thread high-water-mark is constantly increasing and your stack cache always misses.
Re:Why We Use Go
by SamReidHughes on Friday May 29, 2015 @03:11AM
(#9623174)
Could you find out the names and addresses of people making these benchmarks? If so, that seems like it would be a relatively easy problem to fix.
(Edit: I mean of course so we could allocate memory at their addresses for better locality, this is HN after all. Other ideas would need to be pulled to a different arena.)
Re:Why We Use Go
by Manishearth on Wednesday May 27, 2015 @12:14PM
(#9612387)
I'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.
> The attitude of the decision making around the language is unfortunate, and I think Go could really take a page from Rust’s book with respect to its governance model.
(I wrote part of Rust's current governance model and was a part of polishing it up; though I wasn't so involved when Rust initially started using a consensus based model. I've also tried Go, and written about it [1])
... I don't know if this would work out so well. One of Go's strengths (also weaknesses, but it is a strength) is that the language designers can afford to just make hard decisions for everyone. This is where the simplicity comes from, IMO. Rust is complicated because it tries to cater to a wide range of needs. Go makes decisions even if they cut out use cases, and the language stays simple. Both approaches are valid; but IMO switching approaches would make Go lose one of its best plus points.
[1]: http://www.polyglotweekly.com/2015/04/24/thoughts-of-a-rusta...