GoLang has started to skyrocket in popularity over the recent years. GoLang is not a new programming language; it was conceived back in 2009 around the same time as NodeJS. Its recent gains in popularity come down to its advantages which include fast performance, portability and cloud-nativeness. In addition, GoLang is now one of the top paying programming languages.
However, this article is not a comparison of the advantages of GoLang vs. NodeJS. Much of that is already covered around the web. Instead, I’ll be talking about how practical GoLang is for startups like ours and why we made the decision to ditch GoLang for NodeJS.
In the Beginning…
Let’s start from the beginning. We started out with a backend stack comprising GraphQL, PostgreSQL and of course GoLang. Our engineering team started out as a band of two people — one person in backend and another in the front end working on our iOS app. When I joined the team, these two engineers were log gone but left behind a backend full of issues.
No ORM was used so queries to the database were made explicitly. The queries written were so inefficient we kept hitting memory limits and we encountered long wait times before queries were fulfilled. The code had no architecture; it was a complete jumble of code with files all over the place. No GraphQL library was used with GoLang. It was clear the previous backend engineer was trying to go completely vanilla which was not an ideal path to take if you want to scale quickly.
GoLang Itself Was Not the Problem
None of these issues are GoLang specific problems. These were problems introduced by an engineer who was not competent with GoLang. This presented our startup with a problem. There are very few GoLang engineers and even less competent ones. We found ourselves hiring and dismissing two GoLang engineers each attempting to patch the problems in our backend but without success. Competent engineers are expensive and at the time well beyond the budget of our young startup.
As a startup we were racing towards bringing an MVP version of our app to market and this meant we needed speed. A small set of libraries available for GoLang and GraphQL coupled with a small community meant we were hacking our way through problems at a slow pace. Add to this our inexperience with GoLang, we spent more time fixing problems than building features. The app itself was destined to become more complex which meant things were not sustainable in the long term. We needed an alternative.
The Move to NodeJS
At some point, we sat down to discuss re-writing our backend. We needed to address the following issues:
- We needed a competent backend engineer at a fair market price our startup could afford.
- We needed a backend stack with lots of pre-baked solutions to common problems to move at speed.
- We needed a backend stack with enough resources out there to solve for less common problems as we approached complexity.
Our decision was to replace GoLang with NodeJS. This addressed all our issues which really centered on speed and cost.
- NodeJS has a larger market of engineers available than GoLang.
- Experienced NodeJS engineers are much cheaper than GoLang engineers.
- NodeJS has many existing packages to solve for common problems enabling us to focus on building our app and not fixing the app.
To conclude, our decision to move to NodeJS was largely based on business dynamics of our startup. Whereas it’s often debated whether NodeJS or GoLang fits into your project depending on technical merits of the project, ours came down to what would move us forward from prototype to MVP in a reasonable time frame.
