On Thursday, 10 July 2014 at 02:12:18 UTC, Atila Neves wrote:
Rob Pike has said multiple times that the key/unique thing about Go is "select" and that goroutines are the easy part. I'm not entirely sure I grok what he means but we should if we're going to try and do what they got right.
Select is vital for Go in the sense that without it there'd be no way to do non-blocking send/receives on channels in Go. It's much more concise than the alternative, which would be something like `if chanA is empty then foo(chanA) else if chanB is empty then bar(chanB)`. It also avoids starvation by checking the channels in a random order - unlike the previous if-else chain, which would never call bar(chanB) if chanA was always empty.
It's been implemented in Rust[1] via a macro, and can be implemented in Haskell[2] without compiler support, so I'd be surprised if it wasn't already possible to implement in D. It wouldn't however be as useful as Go's until D gets message passing between fibres.
Actually, an important question that should be considered: does D want actor-style concurrency, like Erlang and Akka, or CSP-style concurrency, like Rust, Go and Haskell? Or both? Deciding this would allow efforts to be more focused.
I personally think either would be great, and sufficient to make me consider D for any of the work I'd currently use Go. D currently however has neither. It technically implements the actor model in std.concurrency, but using OS threads, which significantly reduces its utility (one doesn't just spawn 100k OS threads).
1. http://thornydev.blogspot.com.au/2014/03/select-over-multiple-rust-channels.html 2. http://stackoverflow.com/questions/24611801/how-to-implement-the-equivalent-of-gos-select-statement-for-haskell-stm-channel
