Go’s 1.0 version was released in march 2012, and while the Go community has been growing at a steady pace, it took two years for the very first Gophercon to happen. By their own confession, the organizers were a little bit surprised to see so much enthusiasm, as around 700 gophers from all around the globe swarmed Denver. We could not miss that. :)

TL;DR Grab the slides here.

The venue was definitely very good: slightly on the splurge side, but that may be me attending too many un-conferences, and hack-meetings lately. The speakers were great, inspiring, and we were even treated to a nice hacking room, that I have been (ab)using to jot down some notes, instead of, well… hack. I hope that using VIM still counts for something.

The conference is now over, and this is a good time to recap some of the talks and conversations of these past days.

What can be said of the gophers I met in Denver is that:

• they are very helpful,
• they like to learn and share,
• they are building killer robots,
• they sometimes leave Ruby conferences early to attend Go conferences,
• and they also are mostly males (disclosure: I am mostly male myself).

Day 1

The first conference day started very slowly for me: registration had to open as early as 7:30AM, so that the talks could start on time an hour later (they did), but I sleep-walked until caffeine finally kicked in, as Rob Pike went on stage. Good timing.

Rob Pike’s opening keynote

While Go is a fairly young language, its design is actually the result of many years of experimentation. For example, Hoare’s CSP formal language has had a huge impact on the design of Go’s channels. Surprisingly, C++ also played an important role too, as a collection of anti-patterns to be avoided. For instance, Go compiles very fast because C++ does not: the legend is that Go’s inception happened while waiting for C++ programs to build…

If you used Go in its first years, maybe you remember having to deal with the 6g, and 6l programs (or 8g, …). Starting with Go 1.0, these tools were hidden from the developer in favor of the much terser go build command, which made the whole deal a lot simpler. Go has great tools.

But more than sweet tools, it is the stability of the language (its syntax, and features) that brought a lot of developers to it. So, the release of go 1.0 was a bigger milestone than we might think: the community really picked Go as a serious programming language because of that particular version: here is a mature language, it is free, fast, and we will not change it.

Go appeared first as a server language (or cloud language as we say these days), intended to replace Java and C++ inside Google’s infrastructure. So it is very good in these particular domains, but of course many programmers have other plans, and it is exciting to see where will Go go next (ho ho).

Kelsey Falter: From Node.js to Go

This talk had so much potential for trolling that it would be criminal not to mention it.

Kelsey Falter is Poptip’s CEO. Her company’s main focus is doing "social analytics" on Twitter: imagine asking your 10 billions followers what is their favorite programming language, you would get a lot of noise rather than a conversation (and quite possibly you just started a war). Poptip employs magical elves to read every Twitter reply you would get, and provide you with an actual answer.

Well, the truth is they actually bootstrapped their lead product using Node.js, with Express and Mongo, a well known stack. It allowed them to grow and get noticed fast. However, they also ended up with a big, hardly maintainable, Javascript code base, and very little time for rewriting or refactoring.

From there, rather than throwing more Javascript at the wall, they cautiously started replacing key pieces of their infrastructure with more efficient Go programs. Consequently improving their response times: parsing JSON is apparently faster with Go. This switch conveniently allowed them to sustain traffic spikes, and DDoS attacks (that is, until MongoDB collapsed…).

I think that the lesson here is not that Node or MongoDB completely suck (we shall not rip off Hacker News from its favorite troll), but rather than you should plan your architecture carefully, and use the right tool for the right job.

Brad Fitzpatrick: Camlistore & The Standard Library

If you have seen some recent talks from Brad Fitzpatrick, they usually focus on his favorite Go project: the Content-Addressable Multi-Layer Indexed Storage, or Camlistore for short.

When Brad Fitzpatrick joined Google, he had to work with the Google-blessed languages − Python, Java, or C++ − which he did not seem to enjoy very much (understandably). So it came that in 2010, he gave Go a try for his new CMS pet project, because he wanted:

• something to do while riding the bus,
• threads, that is to say, actual, non GIL-locked threads,
• and fast compilation.

You can use Camlistore right now. Install it on one or more machines, or on your Android device, and start synchronizing them around.

The fact is that developing this project alongside a very young Go ecosystem helped a lot in debugging and implementing features that everyone can now enjoy. After about a year of submitting patches, Brad Fitzpatrick finally joined the Go team, and thanks partly to Camlistore, contributed to "a few" packages: http, json, png, jpeg, syscall, etc.

His talk ended with a little announce about the things that we get to see soon in Go’s 1.3 release, and that are also related to his work on Camlistore:

• sync.Pool: reduce garbage and standing memory usage,
• copying stacks: no random performance fluctuations,
• precise GC: important for 32-bit ARM Android builds,
• m[string(byteSlice)] is now free.

By the way, Go 1.3 is available in beta at this time, so you are encouraged to try it and report bugs. A longer changelog, and design documents for this version are also available directly on the Go community wiki.

day 2

Russ Cox’s keynote: Go from C to Go!

Russ Cox was opening the second day with a keynote about the rewrite effort of the Go compiler, currently a C program. This is due to various reasons: the most prominent one being that there was no Go compiler to compile itself when the project started.

C was originally written in 1972 at Bell Labs, and to quote Dennis Richie, it is “Quirky, flawed, and an enormous success”. But today, Go is mature and fast enough to be its own compiler. Furthermore, having a compiler written in Go will allow the team to use all the Go profiling tools to optimize the resulting program.

Another good reason to do such a conversion it that, right now, to contribute code to the Go compiler, you need to be both a Go expert and a C expert. Hopefully, a nice side-effect of having a Go program would be to get more contributions from the community.

To convert the C code to Go, the team has chosen to write a program, rather than do the work manually. This should avoid human errors, even if it also induces a number of challenges, notably generating human-readable code. More generally, while C and Go have a relatively similar flow, some problematic differences are to be addressed:

• C Macros (#define, #include), having no equivalent in Go, require special treatment, unless they can be rewritten (some #defines can be replaced by constants, and so on…).
• While unions do not exist in Go, a cute work-around in C would be to think of these as #define union struct: this macro would replace all unions definitions by structs, wasting some space, but the resulting behavior would be equivalent (as long as you are not writing obfuscated code). It was actually inspired by an old C joke, which promotes the opposite: #define struct union /* Great space saver! */. :) (Yes, you have to know a little C to get it).
• Code comments need to be preserved, and then attached to the correct source locations.
• gotos have different rules in C and Go: for example a jump over a variable declaration is not authorized in Go.
• Various types needs to be mapped correctly from one language to the other. C uses pointers (integer values) to manipulate arrays, and for these the converter has to be able to infer the underlying array types.

Although the scope of this “transpiler” is limited to the Go compiler, it is nonetheless a very interesting project, because as far as I know it is the first initiative to convert a large C code base to Go.

Currently, the project is at the prototype state, and the target Go release is 1.4 ; so until that wait and see.

Victor Vieux: Making Docker GO: Why One of the Fastest Growing Open Source Projects

Docker is one of the fastest growing open-source project. Originally planned as a rewrite of a Dotcloud internal tool, it took a whole life of its own. The project has around four hundred different contributors, and has been "starred" on github eleven thousand times.

But what is Docker? In short, Docker is a lightweight Linux container. Docker containers are both platform and hardware agnostic: meaning they run equally well on your laptop, or up in the sky on your cloud servers. This makes them the ideal building blocks of a cloud-based architecture, because it could allow scaling by merely firing more containers. And with that, my buzzword bag is almost empty.

The open-source community has started building many great things around Docker:

• CoreOs a lightweight OS.
• Drone a CI server.
• Victor Vieux demoed his GoCover web application: it fetches random Go packages from Github, run their test suite, and computes the code coverage of these tests. To avoid contaminating the host system, each test suite is run in a separate Docker container.

We have been watching Docker for a little while at af83. While the project has not reached version 1.0 yet, it has gained a lot in stability and maturity ; as a consequence, we are starting to consider it as a part of our architecture. The easiest entry point, in our case, will probably be our CI system, still running the venerable Jenkins.

Andrew Gerrand: Closing keynote

Andrew Gerrand joined the Go team a few years ago. After years coding in Python, Javascript, or PHP, switching to the Go language has been a very different experience. In his talk, he shared some of the lessons of four years spent working with Go. This was a great closing keynote, full of insights, and anecdotes regarding short code snippets.

If you get the chance, you should watch the recording when it comes online ; meanwhile the slides are also available.

To say that Go’s type system is simple is an understatement, especially when compared to Java, C++, or more modern languages like Haskell. The rationale for this is that less is more. Go’s type system really shines when you start using interfaces rather than concrete types in your code and APIs.

Go’s concurrency is probably its more advertised feature. If you wrote concurrent code in other languages, manipulating native threads, or using event-loops, then you are used to having a lot of control over the execution and (sometimes) preemption of threads. Go has radically departed from these models, for it does not let the programmer know in which thread her code is running, nor does it allows one to interact with threads (“why can’t I wait on or kill a goroutine?”).

This design prevents the programmer from using thread-local storage. It also encourages the use of Go channels as a very elegant tool to communicate state between execution threads. Concurrency is not only an excuse to write embarrassingly parallel code, it also helps writing better code.

The first few days you start coding in Go, it feels like all you are writing all day long is this:

if err != nil {
    return err
}

The handling of errors is very explicit in Go, and this decision was made to avoid hiding them as much as possible. This gently forces the programmer to think about errors: for instance, I do not know one Ruby programmer who has never been bitten by a missing rescue clause.

Go does not let you do that, errors happen all the time. As such, they should be clearly handled, not pushed at the bottom of a function by a try/catch block.

Andrew Gerrand’s concluding words were “Let’s build small, simple, and beautiful things together”. Indeed, let’s do that. :)

About this short report

These two days have been very dense, and this short report can not hope to do justice to all the great speakers, and gophers, present at the event. It is merely a selection of the themes that particularly interested me.

If one thing, this first Gophercon shows that the Go community is really active. Not only in the United-States, but also in Asia (just check how many books are currently available in Japanese or Chinese), and Europe.

Go is definitely a language with server roots. It is production-ready, and used by many companies around the world to power a growing number of critical services and APIs. For instance, if it is good enough for Google, maybe you should consider it too.

Gophers are pushing their favorite language to new fields as well, and I am sure that we will soon be able to count on Go to write desktop and mobile applications.