[akjha]

Interesting. What are some the benefits you felt with Go in comparison to Node.js?

We already have a largish (couple hundred thousand line) Node.js app written in Typescript and are looking towards other alternatives for the future product as I am not very happy with the quality of Node.js ecosystem.

[dcuthbertson]

Sorry for the late reply. There are a few advantages to go.

1. we don't force our customers to lay down a large Node.js blob just to run our software.

2. The old code was written for an old version of Node.js, v4.x, I believe. As such, it was full of code suffering from callback hell, and a lot of anonymous functions written inline. It was very difficult to reason about when tracking down bugs. I'm sure your Typescript code is far better organized.

3. The edit-compile-test loop is far faster. It takes less than a minute (20-50 seconds) to compile the new codebase, which is a mix of Go and C apps and libraries. The developers use a simple build script to rebuild everything from scratch. The old codebase, a mix of Javascript and C apps and libraries, was built with CMake to manage dependencies. Each rebuild would complete in a few minutes for small changes, but could take about 10 minutes if the "right" code was touched.

4. Like theshrike79, I find Go's concurrency patterns, channels, and goroutines a delight to use.

5. We use json files for configuration. Go has a simple scheme for converting between json and structs. Node.js allowed us to make poorly structured json files. When we converted them to follow some simple nesting patterns of structs within structs, converting between structs in memory and json files was just too easy!

It seems that the new codebase is significantly smaller, so it's easier to find where things are implemented. Part of that is getting rid of tech debt and being very familiar with the new code.

When we were still in beta, we ran some performance tests. They indicated the new code was as performant as the old node code (which has been worked on for years). We expect to be able to improve on that as we have time.

I hope that helps. It's been a major amount of work to rewrite our apps while maintaining the old code base - not something to do on a whim. I know the dev team is delighted with the results. Good luck.

[theshrike79]

In my experience the active aversion to all kind of magic make Go code more maintainable even if you're not familiar with that particular part of the code base.

Stuff goes in, stuff comes out. You don't need to wonder if something outside of the scope magically comes around and changes things in the middle.

Also Go's concurrency pattern with goroutines and channels fits really well to my mental models of how stuff tends to work in my field.