Go borrows key concepts from Erlang

The Go language, getting a lot of attention because it was recently open sourced by Google, seems to be a sort of programmers’ Rorschach test in that everyone calls it a replacement for C++/Python/Erlang/Your Language Here… My sense is it wouldn’t be getting that much attention if it were released apart from Google. But thinking about Go for the past few days made me realize that the most important part about Go is actually its “Erlang-ness”. Everything else it provides is nice if you’re a C++ developer doing systems programming already, but not critical. But the goroutine/channel piece is the part that actually differentiates the language as something worth investigating that you can’t easily work around with the existing toolset.

Would it replace Erlang for many applications? Probably not, because though the coroutines will be powerful in certain systems, Go is not a platform like Erlang, with all the benefits of hot swappable code, supervisor processes,hibernating processes, etc… To a non-developer I would describe Go as containing some of the building blocks that make Erlang a great language and platform, but ultimately Go is targeting lower-level systems development. That type of coding wouldn’t be a good fit for Erlang anyway.

So where would they overlap? Probably most likely the two languages would be in applications that are not too OS-level but not too application-centric where OTP or hot-swapping code, multi-machine communication, etc would be requirements. The most obvious example would be web infrastructure. Would Go be a good fit for writing a web server vs Yaws or Mochiweb? Probably. Would I want to use Go to write my own cross-node communication that i get for free with Erlang? Probably not.

So I’m realizing that Go provides a service to the Erlang community in that it validates the fundamentals of the Erlang platform. Goroutines are equivalent to Erlang processes:

Why goroutines instead of threads?

Goroutines are part of making concurrency easy to use.  The idea, which has been around for a while, is to multiplex independently executing functions—coroutines, really—onto a set of threads. When a coroutine blocks, such as by calling a blocking system call, the run-time automatically moves other coroutines on the same operating system thread to a different, runnable thread so they won’t be blocked. The programmer sees none of this, which is the point. The result, which we call goroutines, can be very cheap: unless they spend a lot of time in long-running system calls, they cost little more than the memory for the stack.

And Channels to Erlang messages: ( see slide 28 from this deck)… very cool stuff and further evidence of the slow but inexorable march toward mainstream multi-core programming.