4 ms·

Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps

by Guthur 5y ago

Nope, as a language Go adds nothing and sometimes feels like it gives even less. Where Go has been a success is tooling. The tooling is pretty decent and helps a lot. But that could be added to pretty much any language ecosystem

masklinn 5y ago
> But that could be added to pretty much any language ecosystem Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice. Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.
Cthulhu_ 5y ago
Go apologist here. Go doesn't work because it adds something to existing languages, but because it keeps things away. In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness. That said, for me it's not so much Go itself, but the mindset that comes with it of writing dumb and verbose but obvious code. I've reduced 15-line for loops into clever functional oneliners, but maybe all I needed was a `range` instead of a `for i = 0` style loop all along, because I need a lot more time and mental energy to understand the functional oneliner than a `for x in range` loop.
- kaba0 5y ago
  That’s a bit bold coming from a relatively young language, given that Java has codebases close to 25 years old. Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.
  - throwaway894345 5y ago
    Some of us were around when Java was young and can compare a 5yo Go codebase with a 5yo Java codebase :) > Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions Repetition is not a big deal in a local context (e.g., error handling or for loops), and Go is rarely repetitive in larger contexts. Gratuitous abstraction is a much greater danger than extra keystrokes IMHO.

by Guthur 5y ago

masklinn 5y ago

> But that could be added to pretty much any language ecosystem Though it annoyingly is not. The profiling with integrated stack, line, and memory / alloc profiler seems especially nice. Though it’s made progress (especially with the rise of flamegraph-type visualisation) the ecosystems I navigate seem to remain a hodge-podge of disparate tools.

Cthulhu_ 5y ago

Go apologist here. Go doesn't work because it adds something to existing languages, but because it keeps things away. In 30 years time, Go codebases built today will still be around, while Java, Javascript, Scala or Ruby codebases will have been rebuilt multiple times over or removed entirely, because they drowned in their own complexity and their developers' own cleverness. That said, for me it's not so much Go itself, but the mindset that comes with it of writing dumb and verbose but obvious code. I've reduced 15-line for loops into clever functional oneliners, but maybe all I needed was a `range` instead of a `for i = 0` style loop all along, because I need a lot more time and mental energy to understand the functional oneliner than a `for x in range` loop.

kaba0 5y ago
That’s a bit bold coming from a relatively young language, given that Java has codebases close to 25 years old. Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions.
- throwaway894345 5y ago
  Some of us were around when Java was young and can compare a 5yo Go codebase with a 5yo Java codebase :) > Also, repeating the same code many times due to lack of expressiveness is not the epitome of long-lived software. Essential complexity is non-reducable, the only way we can deal with it is through abstractions Repetition is not a big deal in a local context (e.g., error handling or for loops), and Go is rarely repetitive in larger contexts. Gratuitous abstraction is a much greater danger than extra keystrokes IMHO.