This vulnerability scanning 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.

the caveats of go

On the embedded side of things, it’s all about reproducibility. When go imports libraries, it’s all done on the fly (unless set in the environment otherwise).

When I removed one line and broke my entire codebase in an OpenStack instance, I really thought that it was a change that I implemented.

So I add it back.

It’s still broken.

?????

Turns out, it was a dependency that was recently changed, which made it incompatible with the current implementation. That was too much unnecessary time wasted debugging…

Also, this is 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

There’ll be support for better error handling!!! And generics I supposed.

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).

hey ho let’s go!

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. ♥