Last Friday, most of the Mention tech team spent the day at the dotGo conference. It was the first European conference about Go, the server-side language initially developed by Google. This event is part of a larger series (dotScale, dotJS,…you get the dot!) organized by the amazing guys behind dotConferences.

A happy Gopher couple before the show :)

Team event

These kinds of conferences are unique occasions for us in the tech team to spend an entire day together in a different context, acting like a one-day team building event.

It gives us the opportunity to learn about other technologies or subjects not directly linked to the ones we’re dealing with everyday (for instance, it was a great opportunity to dig into the back-end world for Richard our Android Developer who’s doing mainly Java and mobile development).

For us, it’s very important to keep this spirit of openness in the team (and obviously across the entire company). It’s a great way to be sure that everyone on the team understands what problems and solutions others are dealing with in the company.

A European vibe

At the beginning of the event, Sylvain Zimmer, co-founder of dotConferences, ran a poll to identify the ratio of Europeans compared to French people in the audience. Surprisingly, and for the first time in their history, the trend had been reversed, meaning that most of the people there were coming from all around Europe, not just France (generally it’s about 30-40%, still high!).

When you think about it, it’s fascinating to have the opportunity to meet with developers coming from so many different countries, each one bringing their own (technical) culture to Paris.

I guess it’s a real accomplishment for them to transform Paris into a technical hub, at the European scale.

Come for concurrency, stay for interfaces

If you haven’t done so yet, I invite you to spend an hour or two to complete the Go tour which will provide you with a complete overview of the language and a great occasion to meet the famous Gopher!

The famous Gopher


The title of this section is highly inspired by the talk given by John Graham-Cumming from Cloudflare. It was about how easy it is to solve simple problems in Go — easier than most scripting languages, according to him — and how easy it is thanks to Go’s interfaces to refactor your code when it becomes more complex or when the specs change. In his example, he started by processing a large list of domains to find the ones using CloudFlare’s DNS. He spoke about being asked to process the same kind of list, but for different purposes, giving him the opportunity to make his original code more generic and flexible.

Coming from another language, dealing with concurrency can give you headaches.

In Go, one of the first things that will surprise you is how easy it is to start dealing with concurrency. It’s as easy as prefixing any function with the go keyword and voilà! I won’t go deeper into this aspect of the language (mainly because smarter people than I have already spent time explaining it), but it’s definitely one of the main reasons that people give when asked why they considered Go in the first place.

Surprisingly, after having spent some time coding in Go, most people stick to it because of another interesting aspect: interfaces.

Go comes with a unique model for dealing with interfaces. In most Object-Oriented languages, classes implementing interfaces have to explicitly define it.

For example, in Java, to define and implement an interface, we have to write:

Any other class with a String() method which is not declaring that it’s implementing the Stringer interface will not be recognised as a Stringer instance by the Java type system.

Following the example, you can’t do this in Java:

Because NotExplicitStringer class is not explicitly implementing the Stringer interface defined above, the Java compiler will raise an error:

In Go, a struct (the Go class-like concept) matches with an interface the moment if satisfies all the methods (name, arguments type, and return value) defined into it, even if this struct is not explicitly declaring that it’s implementing the interface (actually you can’t explicitly do it).

Following the same example in Go, we should write (code from the standard library):

Any type with a String method will be considered as a valid Stringer by the Go compiler, as the example below shows:

In this code, we never wrote anywhere that ImplicitStringer is a Stringer. Yet, Go is able to compile and run this program and prints the expect result, “42”. There is other aspects of Go demonstrated in this example and I invite you to take some time to analyze it.

Implicitly satisfied interfaces (go here to see it them action) are really powerful. They provide a way to nicely decouple your code from external packages by accepting any class satisfying an interface’s constraints, rather than only accepting concrete classes of the package. Mocking or switching between implementations becomes super easy.

In a way, it can be seen as a form of duck typing, but with more guaranties (provided by the type checks at compile time) and performance.

From the outside, it does not look like the most exciting feature in Go (compared to the easiness in dealing with concurrency) so it’s interesting to observe that this is actually the feature that makes people stick to the technology (even if it obviously contributes to it a lot!).

Ready to scale in production, not in communication

At the end of the day, the most important thing I took away was the paradox between the number of attendees who said they used Go for large scale purposes (like ours at Mention) thanks to its maturity and design choices, and the fact that most speakers spent their time to explain to us how amazing Go is.

The talks gave me the impression that Go is still at its evangelization phase in terms of communication. There was a real difference between the audience (another poll conducted by Sylvain at the beginning of the conference showed that most of the attendees have already developed at least one application in Go) and the focus of the talks.

Maybe the focus was not the right one, or maybe, as one of my colleagues suggested, it was because since we booked our tickets in April, people found time to experiment with Go.

I had a lot of fun during the talk given by Felix Geisendörfer about his GoDrone project.  Yet I feel that the community is not yet as ready as the technology itself to talk about the real problems it’s helping to solve.

Still, it was amazing to meet the community coming from all around Europe, and to take part in the great vibe and enthusiasm found in finally having a technology that seems to have managed to mix the pros and cons of most technologies created in the last decade.

In addition to that, it’s always a pleasure to see dotConferences grows, and to see that the issues they’ve experienced in previous editions have been getting solved, making the event even better and better.

One thing is for sure, though, I’ll be at dotGo 2015! Will you?

All the examples shown in this blogpost are available on Gist

Head Of Developer Evangelism @ Mailjet. Passionate about the impact of new technologies on the world. Polyglot developer. Running Addict.

Subscribe to Marketing + Monitoring Weekly

Get hot blog posts, insanely useful resources, and funny gifs every Friday.