3 ms·

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 th

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.
  - james_s_tayler 6y ago
    Does C# rely on VS? MSBuild is separate from VS and you can use Rider (yay!) or VSCode instead of VS. 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.

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.
- james_s_tayler 6y ago
  Does C# rely on VS? MSBuild is separate from VS and you can use Rider (yay!) or VSCode instead of VS. 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.