Semi-edited: Everybody else will say Zero to whatever, and the Hard things about Hard Things, and Jimmie's book Good to Great and Crossing the Chasm, and you might call me mad (and I may be!), I am the only person who will recommend a book called "Eat People". (It is a good book, though)
EDIT2: U - akjha - Please let me know what you thought. You have my email address.
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.
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.
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.
We have been using ANT design for our enterprise SAAS application.
We have been quite happy with it until today when we discovered to our horrors that for some reason, developers of ANT thought it was wise enough to magically insert easter egg which triggers on Christmas day modifying all the button to have a tooltip showing a "Ho, Ho, Ho" message.
To all my fellow developers, easters eggs can be fun but please be judicious about where and how to add it.
i) If you are adding an easter egg, don't make it default behavior. Make it an opt-in.
ii) Document the behavior. Yes, I can see how surprise Easter eggs can be fun but fun shouldn't come at the cost of reliability and trust. I don't want the libraries I use to pull a surprise on me. Especially in a platform like node.js where I have to rely on so many dependencies.
iii) Our software is becoming more and more complex. With complexity comes bugs and security vulnerabilities. Is adding a piece of additional code which doesn't add any utility really a good decision in such a case?
In the end, please have some empathy for your users. Think through what can be the adverse effects of your changes.
Keeping track of and excluding commits authored by others seems a lot of work. I am curious if you use any kind of tooling or process to make it easier.
