The modern software environment with internal and external services has become a distributed system that is constantly changing (continuous deployment). A simpler language based on the unix philosophy(ies) that supports concurrency, expects errors, leverages the internet and ships with great tools is a wonderful thing!
Unleash the Unix!
Talking with dev ops people these days I get the sense that stacks look roughly like this:
Code -> WAR -> Classloader -> Micro Kernel (JBoss) -> JVM -> Docker -> Operating System -> Hardware
Code -> Rails -> RVM -> Docker -> Operating System -> Hardware
Code -> Framework -> PVM -> Docker -> Operating System -> Hardware
Code -> Node.js -> V8 -> Docker -> Operating System -> Hardware
Code -> Operating System -> Hardware
There was a time in the 90’s when most software was developed on an operating system that was not Unix. Having a virtual machine be it Java, Python, Ruby or others that tasted and smelled like Unix was a wonderful thing back then. Now we are in a time when Linux machines are the norm, it seems overly complex to have so many abstractions above the operating system. The security and resource management of Linux (Unix processes) is wonderful.
The vm set of languages with N-tiered stacks (and stacks of n tears) may also be solving the packaging problem. Did I mention that Go compiles to a static binary? So if Docker and friends are being used to help aid packaging and deployment, then Go’s single binary makes for less tears.
Native Lightweight Concurrency
Quad core phones, web service distributed data sources and network IO are not a problem of the distant future. Multithreaded programming done well is hard, 99% of the time I want a safe way to pass messages to concurrently running code. 1% of the time I need to have lower level access. Go solves these concerns natively in a very elegant and simple way.
Errors are not exceptional
With a modern application using web services - internal or external - creates a lot of network errors that are not exceptional. Another common complaint I hear about Go is that the code is littered with explicit error handling. This is surprising because I have found that building a robust application is mostly about handling errors properly. Errors are not an exception and Go treats them like first class citizens, exposing them to the developer where they happen.
The Internets is a great place for lol cats and the source codz
One of the things I get a lot of questions about when I tell other programmers I write Go is why the dependency management is in the source code. This confuses me because we (modern software developers) keep our code in repositories that are on the internet or intranet at least so it has a url right? If we need a specific tag or version we can just use a source code link in our code to refer to the dependency, right? What is strange is that it is easy to just keep a tar.gz of the dependencies with the source code just like any legacy dependency system in another language. I am so excited that there is no large XML file or programming language to manage dependencies and packaging. However it is common to use a Makefile for Go and nothing excludes developers from using XML or any other time consuming build system to compile Go. Usually I point out that you could add the one line compile as an external exec in any build tool but that seems like extra work to me.
The second part of complaints I hear a lot is that unused dependencies failing to compile annoys a lot of developers. As a developer who has worked on many code bases in the 100K (scripting and statically typed compiled) dependency management is a real pain. From a security standpoint trying to make sure all the dependencies are properly updated / patched is a big deal. Removing dependencies especially in a scripting language becomes really challenging as the code base grows. Keep it clean and keep it simple is very attractive after having a few of those headaches.
The language fits in my head which allows me to focus more brain power on solving the problem at hand and less on syntax. Go has very little magic, it looks and reasons pretty much exactly as you expect it to. The systems I work with tend to be very complex with lots of data storage, services and constant change.
Go tools chain
gofmt: This has saved me from having so many conversations I don’t care to have anymore.
godoc: Awesome command line tool for querying the language and by adding -http will start a server so the docs can be surfed also.
go test: Built-in testing package is great!
export GOPATH = $HOME
This just saves so much time. It means all the source code will be in the import path in the developer's home directory. It makes it very unsurprising what version of software is being used. It also makes it easy to make local changes to dependencies locally. It also means $HOME/src/github.com/$USERNAME/$PACKAGE. It is kinda like a convention.
glog for logging
This is the best library I have found besides the one that comes default. The only tricky part is to get it to log to stdout you have to pass the parameter -logtostderr.
fresh is a wonderful tool for automatically compiling
Since I work a lot on web apps and it is nice to not have to compile from the commandline I started using fresh. However since I use glog I need a way to pass the -logtostderr and fresh did not support it. That was ok because in a couple minutes of looking at the code, I wrote a hack in a couple minutes (I submitted a PR) so that I could use fresh with command line arguments.
Choosing a programming language is choosing a set of compromises. When choosing Go, the two compromises that I notice most are: there isn’t a library for everything (yet) and coding Go take a bit more time than scripting. In no way do I use Go for everything, however I have found it more and more attractive for writing programs that can work together. I have noticed Go has become popular with the dev ops and system admins lately. I wonder if it is because in a complex application world, for me Go is like a glass of ice water in hell.
Discussion @ hacker news and reddit.
Discussion @ hacker news and reddit.