Friday, November 13, 2009

Highlights that impressed me from the video on the Go language

Go is a new programming language developed by google and a lot of big names and you can find out all about it on it's wikipedia page here or on it's website here, or you could watch the hour long video here on youtube.

Anyway here are the highlights I got out of that video. I'll still need to read what's on the website to understand the language better, but it does raise my interest now. They wanted quick build times, better support for concurrency and a mixture of the advantages of static and dynamically typed languages. So here they are in no particular order.
  • Very fast compilation. Im guessing on large codebases this can make a big enough difference. It's interesting anyway.
  • Adding methods to anything. To investigate
    1. Does this mean I can add methods to any existing type?
    2. Does this mean I can add methods to an instance of a type?

  • Automatically implemented interfaces. This is kinda cool actually. An interface is declared as a bunch of behavior and anything which exhibits this behavior now implements that interface. Which kinda gives you a duck typing like thing. implements as a keyword does not even exist.
  • Unicode characters can be used in variables. π = 3.14159 is valid code.
  • Making code async is trivial. Declare a function and just type go <function name>. The function executes in an async manner. Apparently whatever threading like thing they've used is very efficient because they demonstrated launching about 100,000 of these goroutines and they all executed in a matter of seconds.
  • Erlang style, you create channels for communications. Channels can carry anything including other channels. You drop stuff into channels and pull them out of channels. This makes writing multi-threaded or client server apps look very simple. To investigate
    1. How easy is it to distribute this over a network? Can I just toss a bunch of goroutines onto other machines?
  • Closures, which should make a lot of people very happy.
  • Reflection. To investigate
  • Dynamic types. To investigate
    1. What is this? Is it like .NET?
    2. Can I call any method on it?
    3. Does it automatically implement all interfaces?
  • 10-20% slower than compiled C code. That's quite impressive.
  • ARM compiler.
    1. huh? Does this mean people can use go to write code for phones and mp3 players?
  • Automatic memory management. There's talk about a concurrent gc.
  • Some important libraries apparently already exist like for html templating and testing.
  • There was something about slices and arrays and maps. Need to investigate further to see if they have anything cool. Like the select, map, reduce type operations on slices or arrays?


  1. Nice article! I was in need of a programmer's perspective of the language. This gives good incentive to start exploring this, as you've said.

    And I guess the really innovative thing is the Go keyword, from which this gets its name I suppose.

    I am more interested in the dynamic nature of the compiler. "Run time reflection". I wonder if it has something to do with a dynamically expanding memory stack which the compiler uses? and wow at portability.
    The golang faq doesn't mention anything about how the data reflection is achieved on a compiled language :p

    Though it mentions about using segmented stack memory for the goroutines to do their job. Interesting, it should prevent any memory bleeds (If at all) after its stable.

    And thanks for the article

  2. I am a big fan of co-routines and Async execution - So Go gets good points in my book for that (I love how F# brings async execution to .NET)- But goroutines sounds very cheesy :)

  3. @vikram : haha I agree the name go lends itself to some pretty cheesy names around this. The async execution model is nice here especially because they don't require people to fiddle around with crap like shared state and locks. The channels make it really elegant :)

  4. oops scratch that. They do have locking. I guess it's just usually unnecessary. Given large enough data structures though, I suppose it will be necessary to fallback to it.

  5. @Vamsi good question. I've been trying to hunt for the information too and I haven't found anything yet. Looks like a deeper search is in order :)