For the past six months (right after the DockerCon) I have been constantly taking some time out to play around with Go, trying to understand why a lot of new tools were being written in this interesting language, especially in the DevOps world.
In the last few days we published our first open source library written in go, godo, and I wanted to share my impression of the language and the platform.
Background
I have no solid experience in Go and you should understand that I come from a scripting background, starting from PHP all the way to JavaScript, 2 languages I both love & hate depending on the day :)
Even though my experience comes from 2 languages and platforms that have been highly criticized over the past years, I’ve had a lot of fun trying to preach towards the adoption of of PEAA, automated testing1 and good abstraction, so I’ve seen both the simplistic / simple and the complex / structured, which is why I always tend to play around with new tools and platforms: one more try, one more point of view.
So, here starts the fun…
Getting started
So, it all started on my way back from Amsterdam
(where DockerCon 2014 was held), I typed mkdir holland
(what else?) and followed an advice a friend of mine
gave me, which was “Golang is really good with concurrency,
[…] go ahead and write your next proxy with it”:
let’s write a proxy then!
The first natural thing was to then write a simple Dockerfile starting with:
1 2 3 4 5 6 | |
5 minutes and I was ready to play with Golang on my
machine, writing my first “hello world” copying
the sample code from golang.org.
Overall experience: it was fairly easy to setup everything on my system, but this is more thanks to Docker rather than Go itself.
Documentation
The next step was to try to find documentation on how to do the simplest tasks with Go, just like I did when I first started learning PHP 7 years ago and JS a few full-moons ago.
To be honest, the experience wasn’t pleasant, at least at first: there aren’t as many tutorial guiding through your first steps with Go and, obviously, I was finding myself in trouble even to simply declare my own packages and understanding how the gopath works.
Luckily, I was able to figure these basic things out
quite quickly, but not quick enough to avoid getting my
wifi being cut off as I was getting on a plane to get back
to Dubai; at that point, the greatest of all surprises:
godoc -http=:6060. Pure magic.
Yes, you can basically browse the whole golang.org website offline, which gave me a huge boost even though I was on a plane, without internet connection2.
Overall experience: what I still find hard is to be able to rely on a plethora of online tutorials on how to do some stuff (ie. SSHing from Go through a gateway), but you can live with it. The offline documentation is really great and, on a broader level, the whole Golang community is making a great effort to give newcomers a clue.
Compilation
One of the I was worried about is that Go is compiled, though it’s also one of its biggest strenghts.
The meh feeling you get once you hear that something is compiled, coming from a scripting environment, is that all of that jazz adds overhead, dead moments that get you out of the zone and so on; luckily, Golang was born at Google which means that it was designed to scale, both in production and during development, else imagine how many man days would be lost in a place like Google, who can count on ~10k engineers3.
As a matter of fact, you can compile the entire Go source in 8 seconds, which gives you a fair idea. Your own software, which will probably use 5% of those dependencies, will probably take less than 300ms, which is pretty ideal.
In JS I would develop much different applications, but if I have to think of how long I wait between editing a file in an angular app and being able to see the changes on the browser, I think it might be around the same time. This is not to compare JS and Go (how silly would that be?) but it’s more to highlight the fact that if you’ve already worked on frontend, the average Go program won’t dramatically change your habits, at least from a development workflow perspective.
And then, Go is fast. How fast? You don’t really care, because your typical use case won’t stress Go that much, but expect it to perform significantly better than scripted stuff like Python or Node.
Of course, it always depends on your application, your need and your coding skills — at the end of the day I can only point obvious truths out, and the fact that something compiled performs better than something interpreted isn’t groundbreaking news :)
One thing I don’t particularly like is that whenever I comment some code, I find that the source hasn’t been compiled because
1
| |
which means that I just commented some code that relied on an external package and now, since that code is not used anymore, the compiler warns me that “hey, why are you importing a useless package?”
Can live with this kind of stuff.
Overall experience: pretty solid. I love the fact that whatever I write can be run on Windows without too much of a hassle, that it produces a binary that just works and that you don’t have to worry about too many things. The transition, in terms of paradigm, was pretty straightforward.
Standard library
Go’s standard library is rock-solid and quite vast: give a look at the list of packages and you’ll get an idea.
The way the godoc commands presents packages, by the way, is
pretty good: you will see the docblocks for every package / function,
along with the annotated source:
Overall, I feel someone’s got my back when I have a problem: you will usually find some package or small utility function that will solve your problem or provide inspiration for your own use case.
Overall experience: I think there is still a lot that can be abstracted and put in Go’s standard library, but the general feeling I have is that’s already very good. Sometimes I miss the (3rd party) modularity that comes with JavaScript, but there are a lot of external packages for Go as well.
Generics
This has been reported to me by more than one person, and I never understood it until I actually had to face the “problem”.
Go’s lack of generics irritates a few people, though I can ensure you can live without them without having to worry too much.
In other words, consider not having generics a feature: you need to live without them and design software in a way that doesn’t allow room for generics or, in other words, ambiguity.
Overall experience: it is probably true that generics add flexibility to your development experience, but like the golang’s website says, they “add complexity and extra cost in the type system and run-time”, so you’ll have to learn to live without them. I am ok with it.
go fmt ./…
I wont waste too much time on this, but let’s just say that, in my opinion, we should have something like go’s fmt in every single programming platform.
Overall experience: A W E S O M E ++
Wonkiness
There are other small weird things that make Go look wonky at first, ie. function visibility:
1 2 3 4 5 6 7 8 9 10 11 | |
These sort of things might seem counter-intuitive, but at the end of the day they all contribute to a more coincise syntax4 and a more pragmatic way of programming.
Overall experience: I would say Go’s wonky enough :) I don’t like the syntax very much, but it’s not like I was coming straight out of the 7th heaven, being used to JS and PHP. At the end of the day it’s coincise and decent enough that I feel pretty ok about it.
Conclusion
I’m very happy of my experiment and I hope I’ll be able to play more with Go, as it seems to fill some gaps where other programming languages / platforms aren’t great at. I believe that the overall development experience is quite nice and the language is pretty easy to pick up, granted you have a couple years of experience with software development in general.
Last but not least, lately I’ve seen so many DevOps tools being built with Golang, and I can finally say we joined the party :)