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.

Comments

“My sense is it wouldn’t be getting that much attention if it were released apart from Google.”

True, but a second-order draw, for people who are actually programmers at least, is Go’s paternity, which includes Ken Thompson and Rob Pike.  Anything those two are doing is always worth a look.

Posted by Michael Turner on 16 Nov 2009 at 17:14

Go reminds me more of Stackless Python than Erlang… Channels are synchronous, there is no selective receive, and all state is mutable.

Bottom line, Go is missing many of the things which make CSPs work so well in Erlang.

Posted by Tony Arcieri on 16 Nov 2009 at 18:36

I think that what you are calling Erlang-ness is actually Limbo-ness. I’ve never been sure how the development of Limbo and Erlang may have influenced one another but there were a lot of similar ideas.

Posted by Noah Diewald on 17 Nov 2009 at 00:28

Hello, of course I came to visit your site and thanks for letting me know about it. pass4sure 1z0-050 Useful information like this one must be kept and maintained so I will put this one on my bookmark list. pass4sure 642-533 I like what you are saying here about safety of medical devices. I do agree with your thoughts on safety. pass4sure 642-731 Thanks for this wonderful post and hoping to post more of this blog here.

Posted by Aiguo44 on 16 Jul 2011 at 12:18

Add comment