4 ms·

I have no interest in Go because it is so limited, more limited than other languages that I have already moved beyond, such as C#. I am far more interested in

I have no interest in Go because it is so limited, more limited than other languages that I have already moved beyond, such as C#. I am far more interested in cutting edge languages such as Rust (borrow checker) or Idris (dependent types) or even C++ 20 (template madness), since these will allow me to express things that I cannot express in other languages. What does Go bring to the table? Note that my perspective is of someone who works in a small team of experienced programmers, not a large organisation with more junior ones.

baq 6y ago
> What does Go bring to the table? junior devs edit: it might sound like sarcasm, but i'm deadly serious.
jahaja 6y ago
> What does Go bring to the table? A still maintainable code base 5 years along.
- 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?
baby 6y ago
Golang brings a language that can’t be abused by programmers like you who will write incomprehensible template madness for all other devs on your team.

baq 6y ago

> What does Go bring to the table? junior devs edit: it might sound like sarcasm, but i'm deadly serious.

jahaja 6y ago

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

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?

baby 6y ago

Golang brings a language that can’t be abused by programmers like you who will write incomprehensible template madness for all other devs on your team.