Tag Archives: multi-process

Google Go

I have just stumbled on an article on Slashdot about Google Go. A programming language which was initially developed internally and it’s now been open-sourced.

Over the past few months I have been working with Erlang on multi-process distributed systems. Concurrency in Go is based on the same model Erlang uses: Hoare’s Communicating Sequential Processes, or CSP.

Go’s concurrency primitives derive from a different part of the family tree whose main contribution is the powerful notion of channels as first class objects.

The thing I appreciate the most of Erlang is how easy it is to distribute – even over a network – and monitor processes. After skimming through Go’s documentation I couldn’t help but notice the lack of integrated network-distribution of processes or goroutines, as they are called.

This for me means that while Go, exactly like Erlang and Occam, simplifies the approach to multi-threaded programming (at least from a developer’s point of view), it doesn’t go all the way and leaves developers to deal with distribution of processes over a network on their own.

This is a perfectly acceptable design choice in the name of flexibility, however it creates a whole new bunch of use cases for the developers to deal with, such as sending channels/channels-data over the network).

What I don’t like of Erlang is its handling of strings, which makes it unsuitable for a number of application that could benefit greatly from its multi-processing capabilities. Very few people would recommend Erlang as a high performance string manipulation language. To quote Sendmail’s case study in implementing their Sendmail load balancing “Client Daemon” in Erlang:

…But Erlang’s treatment of strings as lists of bytes is as elegant as it is impractical. The factor-of-eight storage expansion of text, as well as the copying that occurs during message-passing, cripples Erlang for all but the most performance-insensitive text-processing applications.

Go totally wins on this.

If you now asked me to pick one to use. I’d still go for Erlang.
Functional languages and CSP are changing the way big companies approach the development of business critical applications. In the last year alone I have seen the number of positions advertised for Erlang developers in the financial sector multiply.
Go, if it continues on this path definitely has a chance of making it there. Open-sourcing the language is the right decision to give it the exposure to real-life scenarios that tend to accelerate the growth and adoption rate.

Tagged , , , , ,

Get every new post delivered to your Inbox.