Why I'm migrating from TypeScript / Node.js to Golang

Tools and solutions in programming should always be selected for specific needs. Changing technology and constant evolution are big challenges for any programmer, developer, engineer, as the tools to meet those needs change. That is why when I first took a serious look at the Golang language I knew right away. This will be a longer relationship.

I'm still with Node.js

From the very beginning of this post, I want to clarify the title - I am, and will remain, a developer who is happy to work with Node.js and Typescript. The fact that I am migrating to Golang does not mean abandoning my current environment. Rather, it's a declaration that in some cases and with a specific need I will now reach for Golang.

I saw a large number of blog posts, articles, declarations in social media - even a kind of manifestation from some developers on how they are abandoning one tool in favor of another. I understand this, but on the other hand, sometimes it takes some extreme form where there is a statement like "never again" or "I won't go back to".

I always remember the principle - choose a tool for the requirements of the project. And this means that sometimes (always?) the above declarations completely miss the point.

What was a game changer

Sometimes you check out a language, framework or tool and after a while you know you want to use it. After a dozen years of programming, this happens more slowly, you are more pragmatic, but also automatically - more doubtful. The initial excitement about potential opportunities is not the best, so you give yourself time to cool down.

When I did my first comparison of TypeScript, PHP and Golang for myself while working for a client, I didn't feel at all that Golang was the only and right choice for me. When I started working with it for real, it quickly became clear that there were things I didn't necessarily like.

In fact, I urge everyone to develop a reaction - when you like something, then type "bad sides of ..." into the search engine. Then, on the subject of Golang, for example, you can find and it is worth reading We Need To Talk About The Bad Sides of Go (it's really good one).

It didn't take a long time of working with Golang for me to have similar thoughts to the author of the article mentioned above. At the same time, I was struck by the thought - it is easy in Golang to gain experience what not to do. This may seem like a trivial statement, but if, for example, you look at the entire modern frontend, then it immediately enters the brain that this trivial statement makes a difference.

When bad is good

Let's talk about some example like package scope namespace. I can’t declare anything private and only use it locally with the same name in two files but in one namespace.

In practice, it immediately comes to mind that:

• my packages need to be small;
• I have to take care of what I declare and how I declare it;
• it's good for SOLID principles;

How we interpret and perceive the rules of a language or framework is always subjective. What someone doesn't like may be an advantage for someone else. The more experience and comparisons someone has with other languages, the harder it will be sometimes to accept a different concept.

For me it was like "I will be ok with this idea".

Packages and modules everywhere

I'm passionate about the approach where I break everything down into small chunks. Whether it's frontend or backend, the single responsibility principle is with me constantly.

In Golang I feel in the above context like a fish in water. Everything has to be divided, planned, thought out. There is no space for files with hundreds of lines of code. Creating reusable modules is simple and gives great value.

Regardless of the language I used, the idea of packages and modules has always been promoted by me, and in a Golang this approach is standard.

Of course, there are many other reasons why I like the Golang, but I'll probably write about it here more than once.