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: #definestruct 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.