3 ms·
our JS build time was hovering around 30m for small changes. I built a proof-of-concept backend in go (basically a mirror of some existing services), and was ab
by enahs-sf 6y ago
our JS build time was hovering around 30m for small changes. I built a proof-of-concept backend in go (basically a mirror of some existing services), and was able to build and deploy it in no time flat.
No one knew typescript at our org, but that was a much easier sell despite slowing down the build and HMR significantly.
It was not for lack of knowledge of go either; there were several developers on the team with strong go backgrounds.
Management was unsure of it as "new" technology despite using next.js, typescript. Really, they just were afraid of switching.
To your point about a vertically integrated stack, this is great in an small to medium environment but on a large (and quickly growing team) where the CI looks like a christmas tree and testing is sparse, it was actually quite difficult to manage. Maybe i'll muster up the courage to write a medium post one of these days.
- nawgz 6y agoSounds like you're viewing Go as a silver bullet to endemic organizational issues here, and I find it hard to believe your assertion that Go is going to fix an engineering culture where "testing is sparse"
- enahs-sf 6y agoWe tried to write tests, but they took too long to run. Also there was a great debate over which of the numerous testing frameworks to choose from? Chai? mocha? Cypress for end to end? How it all fits in the CI pipeline? For unit testing, go has a great built-in solution, and with testify you can get the rest of the way there. I don't think go is a silver bullet solution, but when I see something I know can be a lot better and simpler, I generally tend to gravitate towards that.