Go

I heard about the Go programming language in May 2008 and was immediately interested. I spent a couple of weeks writing a preliminary gcc frontend for Go. I’ve been working on it ever since, with just a few interruptions here and there. It’s a relief that this work is finally out there.

Both the language and the frontend are still explicitly experimental. So I was quite surprised by how much reaction it got. I was expecting just a few people to actually try it. Instead, I’ve basically spent all my time since Tuesday responding to comments on IRC and on the public mailing list.

Anyhow, what attracted me to the language is something I’ve written about in the past, namely multicore programming. Go provides cheap threads built into the language (they’re called goroutines) and it provides cheap communication between the threads, via channels. I won’t describe them in detail in this post, but I think that making these the easy mechanisms for multi-core, as opposed to making locks easy, greatly encourages correctness.

Go has a simple philosophy for multicore, which is “Do not communicate by sharing memory; instead, share memory by communicating.” What this means is that when you want two threads to share some data structure, you should do it by using explicit communication between the threads handing off ownership. You should not do it by having them both modify shared memory. Of course this only works if they have some way to communicate, which is what Go provides via channels. The point is that communication can be used to make it clear who is free to modify the data structure, and strict adherence to this approach eliminates race conditions.

It’s far too early to tell whether Go will catch on, but I certainly hope that even if it doesn’t, the basic ideas in the language will become part of programming’s standard tools for multicore.

There is of course more to the language than multicore, and I plan to write a few more notes about it as a I find time between mailing list replies.


Posted

in

by

Tags:

Comments

7 responses to “Go”

  1. fche Avatar

    Do you have a sense whether there is something sufficiently charming about Go to become more of a success than other message-passing style concurrency systems, whether they be libraries like MPI, or programming languages like OCCAM and its descendants?

  2. fche Avatar

    Reading the golang.org FAQ, it’s not clear how much systems-programming code has been written in go so far. Are there any impressive bodies of code yet?

  3. jldugger Avatar

    Finally watched the talk today. My first impression is that Go channels aren’t much different than say Promela’s. Except maybe they’re a bit more thought out. Although I was confused about one bit; at one point he says that channels are synchronized by default, but later implies that sending is not. I guess he means that readers block on the channel, but senders do not?

    So is this rendezvous or not?

  4. Ian Lance Taylor Avatar

    fche: I do think Go has a chance to be a useful programming language. It’s quite easy to write code in it. Having goroutines and channels be builtin and relatively cheap makes it easy and natural to use them.

    There is about 130,000 lines of Go code in the library. There have not been any really substantial Go programs written to date.

    jldugger: I’m not familiar with Promela. When you create a channel, you make it buffered or unbuffered. When you send on an unbuffered channel, you block until there is a receiver. So an unbuffered channel is a rendezvous.

  5. jldugger Avatar

    Promela is the language used for SPIN:
    “Spin is a popular open-source software tool, used by thousands of people worldwide, that can be used for the formal verification of distributed software systems. The tool was developed at Bell Labs in the original Unix group of the Computing Sciences Research Center, starting in 1980.”

    You would think Thompson or Pike would recognize it…

  6. uriel Avatar

    @jldugger Spin is included in the standard Plan 9 distribution, and I think some of its developers have worked on Plan 9, also I know for certain that Russ Cox used it to check some of his Plan 9 work (IIRC it was the APE select() implementation), and I’m quite sure Rob is familiar with it.

    So I would think that they more than recognize it, but are actually quite familiar with it.

  7. Ian Lance Taylor Avatar

    It’s entirely likely that Thompson or Pike would recognize it. I only said that I didn’t.

Leave a Reply