Re: Priority receives in Erlang

[Jim Whitehead II <jnwhiteh@xxxxxxxxx>]

On Sat, Feb 25, 2012 at 1:12 AM, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote:
> All
>
> Has anybody looked at Go? From the Wikipedia article:
>
>  "Go is designed for exceptionally fast compiling times, even on modest
> hardware.[10] The language requires garbage collection. Certain
> concurrency-related structural conventions of Go (channels and alternative
> channel inputs) are borrowed from Tony Hoare's CSP. Unlike previous
> concurrent programming languages such as occam or Limbo, Go does not provide
> any built-in notion of safe or verifiable concurrency."
>
> The question is whether programming conventions could be used within Go that
> would make it static enough to be safe. Something along the line of "Write
> in C, but never use malloc."

I've done quite a bit of work with Go. I presented a paper at CPA this
past year [1], and I'm in the process of writing my thesis which
explores the building of CSP-style concurrent systems using Go.

Go is interesting in that it is still very much a C-style systems
language, with CSP-inspired concurrency primitives. Unlike languages
such as occam and erlang, it still allows shared memory, but the
mantra spread throughout the documentation/examples/community is:

"Don't communicate by sharing memory, share memory by communicating"

As far as concurrency goes, you can spawn a new goroutine to evaluate
a function or method call. This new goroutine is then completely
independent of the original, save for if you provide them with a means
to communicate, such as a channel. Channel operations are synchronous
by default, although they can be buffered to provide asynchronous
semantics when the buffer is non-full.

What I find very interesting about the language is how much it is able
to take from what has been done for years in the occam community.
Although much of the code is not immediately translatable, the way of
thinking is the same. It is fascinating to see C and C++ programmers
suddenly encounter a model of concurrency that is so intuitive and
powerful, giving them new ways to solve old problems.

I'm happy to provide a longer description/analysis for anyone interested.

- Jim

[1]: http://www.wotug.org/papers/CPA-2011/Whitehead11/Whitehead11.pdf