5 ms·

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 gola

by 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.
      - jahaja 6y ago
        > 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. In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar. There's also a slow rot that always creeps in, and unfortunately seniority doesn't always keep "clever" solutions and general over engineering out. But it looks like we'll have to agree to disagree here. > I've seen many instances where errors are ignored by mistake, e.g.: It's true that there's sometime bugs due to mistyping err != nil sometimes. But I have not noticed that it's too often or that it's somehow is such a large problem that it out-weigh the benefits of the clarity and simple flow brings. > At my employer, we use a monorepo and build with bazel. Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison.

by apta 6y ago

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.
    - jahaja 6y ago
      > 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. In my experience this kind of gatekeeping eventually breaks down due to deadlines and similar. There's also a slow rot that always creeps in, and unfortunately seniority doesn't always keep "clever" solutions and general over engineering out. But it looks like we'll have to agree to disagree here. > I've seen many instances where errors are ignored by mistake, e.g.: It's true that there's sometime bugs due to mistyping err != nil sometimes. But I have not noticed that it's too often or that it's somehow is such a large problem that it out-weigh the benefits of the clarity and simple flow brings. > At my employer, we use a monorepo and build with bazel. Hard to compare with an anecdote like that, I just haven't heard much complaints regarding compile times, if anything the opposite, and certainly not that it's a significant problem in a pros/cons comparison.