Things that upset me about Go Lang

arjun dhar
2 min readFeb 16, 2021

I love Go. However love comes with the desire to use it as much and obviously there are things I am stuck with. Ain’t that the way love goes anyway :)

The intent of this write up, is not to diminish the value of Go, but rather to point out the things yo are stuck with if you adopt Go. It’s the things that may annoy you, but must accept to appreciate its finer points.

Myth 1 : Standard library and toolkit is all one needs

Being a late (new)comer, Go tried well to learn from the mistakes of languages before it. Things like a package manager, profiling etc. were offered out of the box by the much acclaimed Go toolchain. While it is quite robust, one of the first things and strong aspects for me is how easy its to debug a language. My personal experience with most people using Go lang is that they don’t even use a debugger and rely on console print statements. This is not a coincidence. The default debugger gdb is by its own admission; lacking compared to the alternative delve.

Another aspect has been package management which has been immature till date evolving from regular unmanaged imports to vendor to go modules.

There are other problems I have had with the standard library and toolkit which would be a blog in itself.

Myth 2 : Go code focuses on readability and avoids magic

A lot of principles hinge on the fact that if you are reading a line of Go then there is no other magic at play. This is also the reason why the error is an explicit return instead of an Exception like in other languages like Java or C#.

This principal also argues against the use of Inversion of Control; which to me was the best thing when working with Java and Spring. There are many people suggesting ways to do IoC in Go; however the official acceptance of this is missing. I tried to unlearn and come around this; however its like the Emperor’s new clothes. I would have gladly accepted this, had it not been for double standards where Go encourages convention when it comes to documentation, unit test, tags, public vs private members of a file.

So Go lang wont use annotations, but will use tags! Annotations is magic but tags aren’t?

Any form of meta data is magic, any form of convention introduces induced magic. Period!

I will keep this blog a running blog to add more notes and technical details in the hope that it will result in less elitist blind conversations and people acknowledge and solve them.

--

--

arjun dhar

Software development enthusiast since I was 8 yrs old. Love communicating on anything regarding innovation, community development … ∞