4 ms·

I tried very hard to bring go into my previous employers environment, but it was all for naught. They are too bought into the JavaScript stack. Case studies lik

I tried very hard to bring go into my previous employers environment, but it was all for naught. They are too bought into the JavaScript stack. Case studies like this would have been super helpful in trying to make my claims.

game_the0ry 6y ago
The good news is that this case study means you were probably right to bring it up as a worthwhile consideration, and you will have these case studies to point to next time.
- enahs-sf 6y ago
  nah, I just quit and started my own company instead. Now I use go on the backend. problem solved.
lstamour 6y ago
It's funny, if you'd asked me almost a decade ago which language would compete with Go, I would not have answered "JavaScript"! Yet, these days I find that's the trade-off: build something "quick" in TypeScript that's easy to modify but perhaps a bit brittle and slow(er) to run in production, vs build something very considerate and optimized in Go but perhaps not something you can easily change without hiring folks specifically for the backend. And then you've Java, which is now trying to be the "VM for every runtime" but is still best at Java itself, for now. I tried running JS-on-Java (graaljs) to improve the performance of JavaScript from "only twice as fast as Python" to "within the top 10 on TechEmpower" but found it had too many compromises to rely on it, it was just another runtime layer I would have to worry about. I end up wondering if the solution really is to begin by prototyping efforts in slower-executing languages to start except where existing conditions and code ecosystems might allow for faster initial results in another language. (Kubernetes projects should likely use Go, etc.) Which is less about Go and more about the need to rewrite software later, I suppose. Then again, these days the problems I end up spending (too much) time on are "which dependency should I use," or "should I rewrite the dependency," I rarely ask myself which language is "better" for a task because I end up having to use languages others are familiar with. Go is not yet universally one of those languages, but the more I see unfamiliar Go code in the wild, the more I feel it could be. One of its current strengths is that its simple syntax and maybe its repetitiveness also makes it quite easy to follow for newcomers.
- wolco 6y ago
  I tried go and it's nice to work with. The use-case of when to with me is limited by other existing good choices.
- zozbot234 6y ago
  I mean, it's hard to see Go as "very considerate and optimized" given the existence of modern, highly-efficient programming languages like Rust, D, perhaps Swift etc. It's obviously better optimized than JavaScript and its derivatives, or even Java/C#, but that's not saying much.
  - lstamour 6y ago
    Rust doesn't have the stability yet that has been a bit of a double-edged sword for Go. And it's taken 5 years for Rust to get as far as it has. I'll be much more interested in using Rust in production when there's more of a "standard library" of options to start with. Right now it has the curse of being both unfamiliar to programmers and not having very many production-ready dependencies available in a larger ecosystem. It might be the "right choice" for the future, but if you don't already know you need Rust, I'm having trouble seeing how typical software can benefit today from Rust, etc., though I really do hope my answer changes over the next few years. :) Swift is definitely something I'd like to explore more, but like Rust, it has few production-ready dependencies available. Kotlin or other Java derivatives on the other hand probably have too many -- if your code is written in Java, I've no idea if it will work great in Kubernetes or if it will expect OSGi or if it's a giant monolith. Which is to say, modern practices can make the JVM a surprisingly practical choice, but most software isn't really all that optimized -- slow and bloated legacy dependencies are both a problem in Java as in Node.js... C# meanwhile can be efficient, but rarely is. And it has toolchain issues due to VS not being open source, and a very small ecosystem of dependencies, plus a history full of corporate rewrites of core functionality. It has a bright future, but its reliance on msbuild and Visual Studio limit it compared to Java. I'd like to suggest C++ but I've spent years learning it and find the complexity overwhelming in side projects. In practice, I think C++ is only appropriate for full-time projects with lots of engineers to validate correctness, etc. The exception I'd make is tiny C++ modules as glue code between languages, or to other existing C code.
saagarjha 6y ago
I don't have the details of how you tried to push this, but often cherry-picking evidence to push your choice of language to your team is not a very good way to run your business. I actually generally dislike case studies like these, not because they aren't interesting, but because people use them as things that they can point to whenever they want to push their personal language agenda (I'm looking for a better word for this that isn't that negative, but until then I hope this comment makes it clear that I don't mean this in a "malicious, purposefully self-sabotaging" way).
- geodel 6y ago
  You are making correct point. Most case studies are kind of lobbying effort to change opinion of decision makers. Sometimes it is done via developers instead of reaching to CIOs directly which Gartner quadrant does. And I think this is all fine as long as people understand it is just opinion sometime of people who are more accomplished. Arguments occur when someone comes in and tell, how they language/Framework/technology is "objectively" superior other people's working solutions.
Scarbutt 6y ago
Server-rendering React and puppeteer are the only two exceptions where I would pick nodejs over Go.
nawgz 6y ago
As a JS dev - the strength of a vertically integrated stack is high. I have a collaborative model editor which can run plugins on the model, and these plugins can be configured to run on the client or the server depending on what they do and what kind of requests they need. This exact same language fuels my API and my client. It means I can share packages everywhere, and a problem solved once & put in a library is solved for the team So, that said - I would also push back against introducing a new language into a stack which everyone shares knowledge of. What benefits did you propose that override such a thing? Or, conversely, why do the benefits I described above not apply to that team?
- 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 ago
    Sounds 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 ago
      We 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.

game_the0ry 6y ago

The good news is that this case study means you were probably right to bring it up as a worthwhile consideration, and you will have these case studies to point to next time.

enahs-sf 6y ago
nah, I just quit and started my own company instead. Now I use go on the backend. problem solved.

lstamour 6y ago

It's funny, if you'd asked me almost a decade ago which language would compete with Go, I would not have answered "JavaScript"! Yet, these days I find that's the trade-off: build something "quick" in TypeScript that's easy to modify but perhaps a bit brittle and slow(er) to run in production, vs build something very considerate and optimized in Go but perhaps not something you can easily change without hiring folks specifically for the backend. And then you've Java, which is now trying to be the "VM for every runtime" but is still best at Java itself, for now. I tried running JS-on-Java (graaljs) to improve the performance of JavaScript from "only twice as fast as Python" to "within the top 10 on TechEmpower" but found it had too many compromises to rely on it, it was just another runtime layer I would have to worry about. I end up wondering if the solution really is to begin by prototyping efforts in slower-executing languages to start except where existing conditions and code ecosystems might allow for faster initial results in another language. (Kubernetes projects should likely use Go, etc.) Which is less about Go and more about the need to rewrite software later, I suppose. Then again, these days the problems I end up spending (too much) time on are "which dependency should I use," or "should I rewrite the dependency," I rarely ask myself which language is "better" for a task because I end up having to use languages others are familiar with. Go is not yet universally one of those languages, but the more I see unfamiliar Go code in the wild, the more I feel it could be. One of its current strengths is that its simple syntax and maybe its repetitiveness also makes it quite easy to follow for newcomers.

wolco 6y ago
I tried go and it's nice to work with. The use-case of when to with me is limited by other existing good choices.
zozbot234 6y ago
I mean, it's hard to see Go as "very considerate and optimized" given the existence of modern, highly-efficient programming languages like Rust, D, perhaps Swift etc. It's obviously better optimized than JavaScript and its derivatives, or even Java/C#, but that's not saying much.
- lstamour 6y ago
  Rust doesn't have the stability yet that has been a bit of a double-edged sword for Go. And it's taken 5 years for Rust to get as far as it has. I'll be much more interested in using Rust in production when there's more of a "standard library" of options to start with. Right now it has the curse of being both unfamiliar to programmers and not having very many production-ready dependencies available in a larger ecosystem. It might be the "right choice" for the future, but if you don't already know you need Rust, I'm having trouble seeing how typical software can benefit today from Rust, etc., though I really do hope my answer changes over the next few years. :) Swift is definitely something I'd like to explore more, but like Rust, it has few production-ready dependencies available. Kotlin or other Java derivatives on the other hand probably have too many -- if your code is written in Java, I've no idea if it will work great in Kubernetes or if it will expect OSGi or if it's a giant monolith. Which is to say, modern practices can make the JVM a surprisingly practical choice, but most software isn't really all that optimized -- slow and bloated legacy dependencies are both a problem in Java as in Node.js... C# meanwhile can be efficient, but rarely is. And it has toolchain issues due to VS not being open source, and a very small ecosystem of dependencies, plus a history full of corporate rewrites of core functionality. It has a bright future, but its reliance on msbuild and Visual Studio limit it compared to Java. I'd like to suggest C++ but I've spent years learning it and find the complexity overwhelming in side projects. In practice, I think C++ is only appropriate for full-time projects with lots of engineers to validate correctness, etc. The exception I'd make is tiny C++ modules as glue code between languages, or to other existing C code.

saagarjha 6y ago

I don't have the details of how you tried to push this, but often cherry-picking evidence to push your choice of language to your team is not a very good way to run your business. I actually generally dislike case studies like these, not because they aren't interesting, but because people use them as things that they can point to whenever they want to push their personal language agenda (I'm looking for a better word for this that isn't that negative, but until then I hope this comment makes it clear that I don't mean this in a "malicious, purposefully self-sabotaging" way).

geodel 6y ago
You are making correct point. Most case studies are kind of lobbying effort to change opinion of decision makers. Sometimes it is done via developers instead of reaching to CIOs directly which Gartner quadrant does. And I think this is all fine as long as people understand it is just opinion sometime of people who are more accomplished. Arguments occur when someone comes in and tell, how they language/Framework/technology is "objectively" superior other people's working solutions.

Scarbutt 6y ago

Server-rendering React and puppeteer are the only two exceptions where I would pick nodejs over Go.

nawgz 6y ago

As a JS dev - the strength of a vertically integrated stack is high. I have a collaborative model editor which can run plugins on the model, and these plugins can be configured to run on the client or the server depending on what they do and what kind of requests they need. This exact same language fuels my API and my client. It means I can share packages everywhere, and a problem solved once & put in a library is solved for the team So, that said - I would also push back against introducing a new language into a stack which everyone shares knowledge of. What benefits did you propose that override such a thing? Or, conversely, why do the benefits I described above not apply to that team?

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 ago
  Sounds 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 ago
    We 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.