8 ms·

> What does Go bring to the table? A still maintainable code base 5 years along.

by jahaja 6y ago

dfgdghdf 6y ago
Is it really though? Go is not expressive enough to model your problem domain in a concise and coherent way, which leads to very large code-bases compared to other languages. Whilst each line is easy to understand in the small (because there is very little abstraction), it becomes extremely difficult to understand how the code works in the large.
- mrmonkeyman 6y ago
  Your "problem domain" is a bunch of boring, easy, simplistic tax and/or logistics calculations and you know it.
- baby 6y ago
  I’ve worked on both large rust and go codebases and I can’t agree with you.
apta 6y ago
No language will magically give you maintainability. I've worked on several year old golang projects and they've been terrible, made worse by the fact that golang doesn't scale well for teams or larger programs.
- jahaja 6y ago
  > No language will magically give you maintainability. That's true. But Go will certainly help with it. > made worse by the fact that golang doesn't scale well for teams or larger programs. What? That's one of the major recognized selling points of Go.
  - apta 6y ago
    > That's one of the major recognized selling points of Go. It's exactly just that, marketing fluff and hype made up by the golang team that is not backed up by actual evidence. Look up several other comments in this thread that mention exactly that. I'm not the only one challenging their false claim. There were never any specific language features that make golang good for large projects. Quick compilation was touted at the beginning, but that went out the window when the golang compiler was rewritten in go. For large projects, it's in the same ballpark as Java and C#, and in my experiences, even slower especially for incremental compilation due to the bottleneck of the linker. Secondly, its features work against scaling for large programs and teams (no generics, verbose and error-prone error handling, interfaces are poorly thought out and optimized for minority use cases at the cost of usability and correctness, etc.)
    - jahaja 6y ago
      You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. > verbose and error-prone error handling Verbose (and consistent) is exactly what you want for large teams. What's error prone about it? You're tone is also suspiciously overconfident which just signals that this is more a you issue. Do you have an example project that has problematic build times in Go?
      - apta 6y ago
        > You seem to be writing that a simple language is somehow harder to scale for large teams I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand. There is a sweet spot in terms of language simplicity/complexity and usability. Make it too simplistic (like golang) and the low modeling ability and inexpressiveness of the language will result in shifting the complexity into the code and onto the programmer, there's no running away from it, it's just reality. IMO, languages like Java, C#, and Kotlin do a much better job at balancing features with modeling power and expressiveness, without sacrificing simplicity. > Verbose (and consistent) is exactly what you want for large teams. What's error prone about it? I've seen many instances where errors are ignored by mistake, e.g.: a, err := foo() if err != nil { ... } b, err := bar() // oops, error not handled and compiler doesn't complain c, err := baz() if err != nil { ... } not to mention things like defer file.Close() // Error not handled and more insidious occurrences (e.g. when was the last time you handled the error for fmt.Println()?) Consistent is good, verbose just for the sake of being verbose isn't. And honestly golang is not that consistent (e.g. the entire nil interface is not nil issue is just bizzare) > Do you have an example project that has problematic build times in Go? At my employer, we use a monorepo and build with bazel. Builds routinely take several minutes, and even more on "less powerful" machines (e.g. 4 cores). Linking time is abysmal, and we routinely end up with 50+MB binaries. It's closed source so I can't share them.

> What does Go bring to the table? A still maintainable code base 5 years along.

by jahaja 6y ago

> What does Go bring to the table? A still maintainable code base 5 years along.

Is it really though? Go is not expressive enough to model your problem domain in a concise and coherent way, which leads to very large code-bases compared to other languages. Whilst each line is easy to understand in the small (because there is very little abstraction), it becomes extremely difficult to understand how the code works in the large.

mrmonkeyman 6y ago
Your "problem domain" is a bunch of boring, easy, simplistic tax and/or logistics calculations and you know it.
baby 6y ago
I’ve worked on both large rust and go codebases and I can’t agree with you.

apta 6y ago

No language will magically give you maintainability. I've worked on several year old golang projects and they've been terrible, made worse by the fact that golang doesn't scale well for teams or larger programs.

jahaja 6y ago
> No language will magically give you maintainability. That's true. But Go will certainly help with it. > made worse by the fact that golang doesn't scale well for teams or larger programs. What? That's one of the major recognized selling points of Go.
- apta 6y ago
  > That's one of the major recognized selling points of Go. It's exactly just that, marketing fluff and hype made up by the golang team that is not backed up by actual evidence. Look up several other comments in this thread that mention exactly that. I'm not the only one challenging their false claim. There were never any specific language features that make golang good for large projects. Quick compilation was touted at the beginning, but that went out the window when the golang compiler was rewritten in go. For large projects, it's in the same ballpark as Java and C#, and in my experiences, even slower especially for incremental compilation due to the bottleneck of the linker. Secondly, its features work against scaling for large programs and teams (no generics, verbose and error-prone error handling, interfaces are poorly thought out and optimized for minority use cases at the cost of usability and correctness, etc.)
  - jahaja 6y ago
    You seem to be writing that a simple language is somehow harder to scale for large teams. My experience is the exact opposite - too expressive language make devs have different dialects and be too "clever" for the teams long-term good - and I'm pretty dumbfounded that you can try to make sense of that. > verbose and error-prone error handling Verbose (and consistent) is exactly what you want for large teams. What's error prone about it? You're tone is also suspiciously overconfident which just signals that this is more a you issue. Do you have an example project that has problematic build times in Go?
    - apta 6y ago
      > You seem to be writing that a simple language is somehow harder to scale for large teams I've worked on a large Scala program before, and because the team generally agreed not to let things get too crazy, it was very manageable. However, I've seen other programs in complex languages get out of hand. There is a sweet spot in terms of language simplicity/complexity and usability. Make it too simplistic (like golang) and the low modeling ability and inexpressiveness of the language will result in shifting the complexity into the code and onto the programmer, there's no running away from it, it's just reality. IMO, languages like Java, C#, and Kotlin do a much better job at balancing features with modeling power and expressiveness, without sacrificing simplicity. > Verbose (and consistent) is exactly what you want for large teams. What's error prone about it? I've seen many instances where errors are ignored by mistake, e.g.: a, err := foo() if err != nil { ... } b, err := bar() // oops, error not handled and compiler doesn't complain c, err := baz() if err != nil { ... } not to mention things like defer file.Close() // Error not handled and more insidious occurrences (e.g. when was the last time you handled the error for fmt.Println()?) Consistent is good, verbose just for the sake of being verbose isn't. And honestly golang is not that consistent (e.g. the entire nil interface is not nil issue is just bizzare) > Do you have an example project that has problematic build times in Go? At my employer, we use a monorepo and build with bazel. Builds routinely take several minutes, and even more on "less powerful" machines (e.g. 4 cores). Linking time is abysmal, and we routinely end up with 50+MB binaries. It's closed source so I can't share them.