3 ms·

> The correct answer is Go I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer. The closest you

> The correct answer is Go I use Go, Node, and C# (also Python, Ruby, and PHP currently) and the correct answer is there is no correct answer. The closest you can get is to use what you know. If what you know can't do the job, then presumably having reached that conclusion you're armed with the knowledge of the missing functionality that lets you do a proper technical assessment of the alternatives with your specific use case in mind.

moomoo11 3y ago
It was tongue in cheek. Both .net and node bring a ton of baggage. If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems. Leave the rest to boot camp devs or enterprise sales trapped companies.
- neonsunset 3y ago
  go is an all around worse choice that requires more effort and LOC per unit of functionalty
  - moomoo11 3y ago
    Wrong but okay.
  - kcartlidge 3y ago
    It often does require more LOC, but unless the difference is extreme (and whilst it's there it isn't extreme) then I'm not sure why LOC would even be relevant. What matters is quality and maintainability of code, not brevity of code. I prefer the expressiveness of C# or Ruby, for example, but do a lot of stuff in Go for the clarity/obviousness of the code and the power of the tooling/libraries/ecosystem.
- kcartlidge 3y ago
  Fair enough. I always consider Go first, but I do differ in that I'm happy to take .Net second. Basically I agree with everything you said there, but with just one amendment - the baggage in .Net was sort of reset not too many years ago with the introduction of Core, and how much you bring into your codebase/tooling is often a personal choice now (depending upon your project) rather than it being forced on you. For example a .Net API can be very clean, fast, free of cruft, and run anywhere from a single binary. A .Net MVC website less so unless you're careful (though I still prefer Razor over Go's default templating).

moomoo11 3y ago

It was tongue in cheek. Both .net and node bring a ton of baggage. If you’re just building services and you want something that gives you solid computational performance and also runs anywhere you can just use go and solve your customer problems. Leave the rest to boot camp devs or enterprise sales trapped companies.

neonsunset 3y ago
go is an all around worse choice that requires more effort and LOC per unit of functionalty
- moomoo11 3y ago
  Wrong but okay.
- kcartlidge 3y ago
  It often does require more LOC, but unless the difference is extreme (and whilst it's there it isn't extreme) then I'm not sure why LOC would even be relevant. What matters is quality and maintainability of code, not brevity of code. I prefer the expressiveness of C# or Ruby, for example, but do a lot of stuff in Go for the clarity/obviousness of the code and the power of the tooling/libraries/ecosystem.
kcartlidge 3y ago
Fair enough. I always consider Go first, but I do differ in that I'm happy to take .Net second. Basically I agree with everything you said there, but with just one amendment - the baggage in .Net was sort of reset not too many years ago with the introduction of Core, and how much you bring into your codebase/tooling is often a personal choice now (depending upon your project) rather than it being forced on you. For example a .Net API can be very clean, fast, free of cruft, and run anywhere from a single binary. A .Net MVC website less so unless you're careful (though I still prefer Razor over Go's default templating).