Processes and Channels, cf. goroutines.

[logicchains]

> What is nice about CSP is that you can proof that your code is 
> free of deadlocks. The Go guys have developed a tool that 
> parses the code and then tells you what it has found.

Note that the Go race detector isn't a static analysis tool that 
identifies deadlocks at compile time; it instruments the code and 
then detects race conditions at runtime. It's based on the C/C++ 
ThreadSanitizer runtime library, so a similar thing could 
probably be implemented for D.

> Goroutines in Go are also co-operative, but I'm not sure (e.g. 
> not pre-emptive).

The Go scheduler can perform a limited form of pre-emptive 
scheduling; from the version 1.2 release notes:
"In prior releases, a goroutine that was looping forever could 
starve out other goroutines on the same thread, a serious problem 
when GOMAXPROCS provided only one user thread. In Go 1.2, this is 
partially addressed: The scheduler is invoked occasionally upon 
entry to a function. This means that any loop that includes a 
(non-inlined) function call can be pre-empted, allowing other 
goroutines to run on the same thread. "

> Rust is basically using the same approach as Go with regard to 
> threading.

Rust is actually moving away from directly tying the language to 
one kind of threading, so that it's possible to choose between 
M:N threading (goroutines) or 1:1 threading (system threads). See 
this discussion: 
https://mail.mozilla.org/pipermail/rust-dev/2013-November/006550.html 
for the reasoning behind this.