5 ms·

I would say 95% of people who are trying to solve a complicated problem with reflection, type erasure, or codegen are solving the problem the wrong way. Obvious

I would say 95% of people who are trying to solve a complicated problem with reflection, type erasure, or codegen are solving the problem the wrong way. Obviously I'm glad these tools exist, and some problems can indeed only be solved with them. But I think people reach for them as a first solution and make bad code as a result. Go strongly encourages you not to reach for bad solutions, which is one of its bigger advantages, in my opinion.

woooooo 3y ago
Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.
- Veraticus 3y ago
  For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.
  - maccard 3y ago
    I've spent a lot of time writing library-level C++, a reasonable amount of time writing application-level C++, and a reasonable amount of time writing both library and application-level golang. > But most people aren’t coding language features It's definitely a tough lever, but supporting generics for the people who are means that the people who aren't can write cleaner code. I think go got it right, eventually.
  - pie_flavor 3y ago
    There is no language feature for a tree map. Many problems require a tree map. Either inclusion of generics was a good thing, or it is worth sacrificing static typing or requiring codegen for these use cases. Repeat for numerous collections and APIs. Disallowing someone from using easy statically typed tree maps is not accomplishing any of the simplicity virtues people trumpet Go for having. While the much-warned-of castles of inappropriately applied generics have yet to be found in any codebase I've worked with in any language, including Rust.
    - Veraticus 3y ago
      This is a pretty arbitrary benchmark. I would guess, again, that 95% of programmers have never and will never need to create a tree map. Repeat for numerous collections and APIs that are totally irrelevant to most programmers' actual experience of programming. Go is optimized for use, not computer science edge cases. And as a result it is widely used, and some of the most complicated and widely-used open-source projects out there are built in it, even before it had generics. For example, Kubernetes. This is because of Go's simplicity, not in spite of it.
      - valenterry 3y ago
        It's not about creating a tree map, it's just about using one. Maybe even one provided by a library, doesn't matter. I'm sure that 95% of the developers will need a tree map at least once in their career.
        Veraticus 3y ago
        I've been using Golang professionally for about a decade. In that time the only place I've ever needed to use a tree map was an interview that specifically called for it. Whose usage are you trying to optimize the language for? Golang is not a good academic language. But it is extremely good for actually solving problems with code.
        Mawr 3y ago
        A tree map is just an example. More compelling ones are sets, ordered maps, a generic sync.Map, optionals (nulls suck!), abstractions over channels - badly needed! I wouldn't consider any of those to be academic.
        kaba0 3y ago
        See the example given from Kubernetes. Is that not a real codebase, or what?
      - pie_flavor 3y ago
  - kaba0 3y ago
    You are writing a Turing complete language. If someone wants to be stupid architecture astronauts, you can’t help them, beside better filtering people who work on your project.

woooooo 3y ago

Collections obviously need to be generic though. Slices and maps were generic from day 1 in go so it's not like this is controversial.

Veraticus 3y ago
For sure — a lot of language features need to be generic. But most people aren’t coding language features, and giving them the ability to do so can lead to, well, CodeFactoryFactoryMakerGenericMethodHelpersFactory, rather than good, clear, usable code.
- maccard 3y ago
  I've spent a lot of time writing library-level C++, a reasonable amount of time writing application-level C++, and a reasonable amount of time writing both library and application-level golang. > But most people aren’t coding language features It's definitely a tough lever, but supporting generics for the people who are means that the people who aren't can write cleaner code. I think go got it right, eventually.
- pie_flavor 3y ago
  There is no language feature for a tree map. Many problems require a tree map. Either inclusion of generics was a good thing, or it is worth sacrificing static typing or requiring codegen for these use cases. Repeat for numerous collections and APIs. Disallowing someone from using easy statically typed tree maps is not accomplishing any of the simplicity virtues people trumpet Go for having. While the much-warned-of castles of inappropriately applied generics have yet to be found in any codebase I've worked with in any language, including Rust.
  - Veraticus 3y ago
    This is a pretty arbitrary benchmark. I would guess, again, that 95% of programmers have never and will never need to create a tree map. Repeat for numerous collections and APIs that are totally irrelevant to most programmers' actual experience of programming. Go is optimized for use, not computer science edge cases. And as a result it is widely used, and some of the most complicated and widely-used open-source projects out there are built in it, even before it had generics. For example, Kubernetes. This is because of Go's simplicity, not in spite of it.
    - valenterry 3y ago
      It's not about creating a tree map, it's just about using one. Maybe even one provided by a library, doesn't matter. I'm sure that 95% of the developers will need a tree map at least once in their career.
      - Veraticus 3y ago
        I've been using Golang professionally for about a decade. In that time the only place I've ever needed to use a tree map was an interview that specifically called for it. Whose usage are you trying to optimize the language for? Golang is not a good academic language. But it is extremely good for actually solving problems with code.
        Mawr 3y ago
        A tree map is just an example. More compelling ones are sets, ordered maps, a generic sync.Map, optionals (nulls suck!), abstractions over channels - badly needed! I wouldn't consider any of those to be academic.
        kaba0 3y ago
        See the example given from Kubernetes. Is that not a real codebase, or what?
    - pie_flavor 3y ago
- kaba0 3y ago
  You are writing a Turing complete language. If someone wants to be stupid architecture astronauts, you can’t help them, beside better filtering people who work on your project.