Opportunities for D

[logicchains via Digitalmars-d]

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