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.
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.
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?
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.
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.
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.
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.
The ecosystem is definitely growing in the last 5 years too since open source has been embraced by MS and the community.
The major rewrite of .NET -> .NET Core and then now renaming it back to .NET again is good in that it's a much better framework now, bad in that it's turning out like Python 2 vs Python 3. Huge projects just can't upgrade, so old .NET Framework stuff is sticking around longer than it should.
They're undoing the split between Core and .NET Framework by suggesting that they'll ship both within .NET 5 using shims or implementations of drop-in replacements for .NET Framework code to use. Imagine if after dropping Python 2 support there was a mode that scanned for Python 2 code and enabled it again, on a file-by-file basis, to work with newer Unicode strings using some kind of translation layer in the runtime. That's kind of what's happening here, I think, but maybe more lightweight than suggested. Legacy .NET Framework code still deprecated, but interoperability libraries will ship as part of the runtime or SDK, will have some amount of shims available. I haven't followed the details closely enough to say more than this, though. I last looked into it a few months ago.
>net5.0
>net5.0-windows
>net5.0_something
So you can use "pure" "net5.0" on Linux and generally cross-platform software meanwhile still be able to use old .NET FrameworkX winforms/wpf on "net5.0-windows".
While Java is generally slow, that's more the fault of Java developers and their FooDangleProviderModuleBuilderBuilderFactories. Due to runtime optimization Java can be nearly as performant as non-GC languages. In principle there are even scenarios where it can exceed the performance of any ahead of time compiled language.
There are idiomatic ways to avoid the GC in Go, and people do that in tiny places, but few people build ground-up that way, because it’s not the kind of program Go asks you to write.