How to avoid Go gotchas

TL;DR by learning internals a gotcha is a valid construct in a system, program or programming language that works as documented but is counter-intuitive and almost invites mistakes because it is both easy to invoke and unexpected or unreasonable in its outcome (source: wikipedia) Go programming language has some gotchas and there is a number of good articles explaining them. I find those articles very important, especially for the newcomers in Go, as I see people run into those gotchas every now and then.

My GopherCon experience

A couple of weeks ago I gave a talk at the largest Go conference, GopherCon, in Denver. It was the first time I attended GopherCon at all, and the first time ever I spoke in English in front of 1400+ people, and it was an absolutely incredible experience. Here is my story. My journey to GopherCon started on a cold winter day in the apartments in the center of Odessa, Ukraine, where I was living at that time.

go get for private repos in docker

As Go community slowly moving towards established and well understood patterns and practices of dependency management, there are still some confusing moments. One of them is automating repeatable build process using containers along with using dependencies in private repositories. Private repositories on Github are often is a source of confusion when using go get, but it has easy workaround by adding two lines to your .gitconfig: [url "git@github.com:"] insteadOf = https://github.com/ or as a oneliner: git config --global url."git@github.com:".insteadOf "https://github.com/" But the most confusing part is trying to make the whole build process work inside the container.

LeftPad and Go: can tooling help?

You’ve probably heard that story about NPM community and LeftPad package, that broke thousands JavaScript projects worldwide. There was a nice follow-up article titled “Have We Forget How To Program” and one guy even created left-pad.io - Left-Pad As A Service web service. People got a lot of fun discussing this story. I personally find this story amazing, because there is no single point of failure, but rather a set of things and coincidences resulted in a disaster.

Visualizing Concurrency in Go

If you prefer video over blog posts, here is my talk on this at GopherCon 2016: https://www.youtube.com/watch?v=KyuFeiG3Y60 One of the strongest sides of Go programming language is a built-in concurrency based on Tony Hoare’s CSP paper. Go is designed with concurrency in mind and allows us to build complex concurrent pipelines. But have you ever wondered - how various concurrency patterns look like? Of course, you have. We’re all thinking mostly by visualization in one form or another.

How to complain about Go

Over the years of existence of Go programming language, the articles with its critique was always popular, bringing a lot of discussion from both sides. Recently, Maksim Kochkin even created GitHub repo with curated list of articles complaining about golang’s imperfection. So, is it true that ranting about Go flaws is a trend nowadays? With carefully gathered links in the repository above, we can check this! :) Unfortunately, there are only 17 articles in the list, which is a bit disappointing because it’s not enough for fine statistical analysis, but we can use this anyway.

Integration testing in Go using Docker

Note: this post was originally written for the Go Advent 2015 series, but I discovered that a post with almost exactly the same subject (and even similar code!) already planned :) That’s amazing. Golang is often used for writing microservices and various backends. Often these type of software do some computation, read/write data on external storage and expose it’s API via http handlers. All this functionality is remarkably easy to implement in Go and, especially if you’re creating 12factor-compatible app, Go is your friend here.

Explaining Go error handling

I recently translated great article — Errors are values by Rob Pike — and we discussed it in our podcast Golangshow (in russian). One thing I was surprised about is that even experienced Go developers sometimes do not understand the core idea of that article. Looking back, I remember my first impressions when I read it for the first time. It was similar to “It looks like Pike just adds some complexity to what could’ve been solved gracefully with exceptions”.