HN Explorer

Ask HN: Rust concurrency vs. Go after drop of green threads and segmented stacks?

4 points by samuell ↗ HN
I have been a big fan of the Go programming language, and how it allowed me to write concurrent multi-core programs with minimal effort.

The lack of generics and an enforced GC still makes me very intrigued of the Rust programming language as an option for many future use cases, especially as Rust used to have something comparable to the go-routines and channels in Go.

After I heard they are moving out green threads to the standard library [1], and also abandoning segmented stacks [2] (something I'm not as much knowledgeable about, but have understood it has implications for concurrency), I'm starting to wonder whether it ever will offer the same strength in terms of building concurrent multi-core programs, as in Go.

Would be cool to have some experts give their views on this, and elaborate a little on what the consequences of those decisions will be, especially compared to what we have in Golang.

[1] https://mail.mozilla.org/pipermail/rust-dev/2013-December/007565.html

[2] https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html

3 comments

[ 2.5 ms ] story [ 18.5 ms ] thread
alco
Just a small note: Go has also abandoned segmented stacks. They were a placeholder until Go got precise GC which enabled it to use contiguous stacks with pointer rewriting. Here's a good explanation of this – http://agis.io/2014/03/25/contiguous-stacks-in-go.html.
samuell
That's a very relevant point, thanks for the link, will check!
bjourne
What exactly are the "concurrent multi-core programs" you wrote in Go doing? Do you have any examples of concrete problems you had that became easier to solve when you used Go's concurrent multi-core features?