I was thrown into the world of Go to develop a vulnerability scanning tool for containers on my last co-op, and I’ve never been so torn on a language as I was during those few weeks of struggle and development.

This tool I speak of is called Clair, and works by using namespace drivers as Go packages. Everywhere from unmarshalling json and xml files, to implementing reflection of non-existent structs, to populating a Postgres database, to debugging through async processes, were all involved in the making.

In some ways, Go is very nicely thought-over and well-designed, the golden love-child of C++ and Python. But in others, I can only say that I wished I’d known sooner, which would have saved me a few hours of painful stepping and debugging.

Hence in that mindset, I decided to start this post: go quirks and common mistakes (aka: what I wish I’d known before I started programming in go).

## some terminology

Terminology first, just to be able to communicate. Might sound a little specific to C/C++ style languages transitioning to Go, but that’s personally how I went.

• nil is null
• slices are vectors

## rookie mistakes

These are the traits characteristic to Go and the nature of this language. I won’t be mentioning mistakes or traits that are general to many programming languages.

Quirky go rookie mistakes:

• unused variables and imports will prevent compilation
• the opening brace must be placed on the same line, else will return an unexpected newline compilation error
• nil cannot be assigned to a string

• the short form of variables declaration can only be within functions: it should be var pi int = 3 instead of pi := 3

• variables cannot be redeclared in the short form either (unless there is at least one new variable being declared in a multi-variable declaration): something like new, old, oldToo := 2, 3, 4 is okay.

## response-specific mistakes

I worked with HTTP responses in Go to scrape my json and xml files. I learned the hard way that:

## the caveats of go

On the embedded side of things, it’s all about reproducability. When go imports libraries, it’s all done on the fly

So when I removed a print statement and broke my entire codebase,

More of a personal opinion on this one but my code doesn’t look too pretty with all these if err != nil { ... } statements…

# bonus: excitement about Golang v2 (hey ho let’s go!!)

support for better error handling, and generics

I’m glad that their decision factors was basically to: address an important issue for many people (as big of an impact as they can), have minimal impact on everybody else (not break Go v1), and come with a clear and well-understood solution (instead of a temporary fix that isn’t well-designed).

On the offchance that you do find a mistake, please shoot me a message and let me know, I would really appreciate.

Also if anyone could tell me where I can get one of those gopher plushies that would be great. ♥