Three Years of Go

C. Dylan Shearer | 14 Jan 2018

I started Jobber more than three years ago. It was this first thing I had written in Go, and Jobber’s need for threads made it a great project for learning this language.

I Like Go

Go is a simple, strongly-typed, memory-safe, compiled language that is good for systems programming. These qualities were in fact the main goals of the language, and so Go’s designers have largely succeeded.

Importantly, Go’s concurrency constructs work very well. Passing messages instead of messing with locks is a great idea.

Let me point out two particularly awesome traits: Go programs are compiled to native binaries, and Go libraries must be linked statically. Once you compile your code, your program and all its libraries are in exactly one file, and you can run that thing on any machine with the right kernel and CPU.

This becomes a huge advantage over languages like Python, Ruby, and Javascript as soon as you start thinking "Gee, it would be nice to use this library in my little program." With Python et al., you have to worry not only about having the right version of the interpreter but also about having the right versions of all the libraries you want to use — and about them being in the right place!

What I Don’t Like

The Build Process

GOPATH , “workspaces”, go get : these things do not work and need to die.

I know how to use git; I do not need go to check crap out for me.

It should be possible to just clone a repo, cd into the project’s directory, and do make . Not with Go. Instead, you have to first futz around with making a workspace, then change GOPATH , and then do make or go build or whatever.

Go presumes that you have one workspace and don't mind checking out all sorts of crap into it, whereas people usually (or they should) prefer having different projects and their dependencies in different places.

(Jobber needs to compile a Yacc grammar, and you may be interested in how I ensure goyacc is there during a build.)

Thank God they added support for the vendor dir.

Nitpick: Pointers and No const

I don’t get why pointers were added to the language. Java’s approach (where all object variables are really pointer variables) seems like it would work.

And Go’s equivalent of void*interface{} — still doesn’t make sense to me.

I hope they add const , in the style of C++. If nothing else, it’s a great way to document the side-effects of functions and methods.