3 ms·

You learn to work around the lack of generics quite easily. Sometimes this means having to write the same code a few times. But if I look at our entire codebase

You learn to work around the lack of generics quite easily. Sometimes this means having to write the same code a few times. But if I look at our entire codebase you're looking at something that impacts less than 1%. I think for most projects the lack of generics is not a major issue.

LukeShu 5y ago
For 7 years I felt that way. That yeah, generics might be nice-to-have in Go, but if you were really sweating it that it meant you were still thinking in Java instead of Go. But then I switched teams at work and... > Me: Nothing has ever made me want generics in Go the way that the telepresence2 codebase has made me want generics in Go. > CTO: Is this because of the problem domain or the incidental structure of the code? > Me: I'm honestly not sure. I want to say the incidental structure of the code, but I'm not sure how else I'd structure it. I implemented codegen/template based generics, but eagerly await being able to replace that with actual generics in Go 1.18. So, I guess the lesson is that it's easy to write off it off when it's someone else having the problem?
- pjmlp 5y ago
  Borland C++ for MS-DOS used pre-processor macros in BIDS 1.0, while BIDS 2.0 replaced that hack with templates. In 2002, Visual Studio T4 was used for generating .NET code shortly after it was introduced. In 2005, Eclipse EMF was used for generating Java code, eventually Java 5 made that unnecessary. As you see, that is a path well known for the last 30 years. Eagerly waiting for Go 1.18, even with CLU like generics.
  - kubb 5y ago
    The funny thing is that in 30 years there will be a new generation of people convinced that nobody needs generics because they happened not to need them in their command line tool replacing a bash script that has grown too large for comfort.
    - pjmlp 5y ago
      Sadly I have been around long enough to agree with your prophecy turning into reality.

LukeShu 5y ago

For 7 years I felt that way. That yeah, generics might be nice-to-have in Go, but if you were really sweating it that it meant you were still thinking in Java instead of Go. But then I switched teams at work and... > Me: Nothing has ever made me want generics in Go the way that the telepresence2 codebase has made me want generics in Go. > CTO: Is this because of the problem domain or the incidental structure of the code? > Me: I'm honestly not sure. I want to say the incidental structure of the code, but I'm not sure how else I'd structure it. I implemented codegen/template based generics, but eagerly await being able to replace that with actual generics in Go 1.18. So, I guess the lesson is that it's easy to write off it off when it's someone else having the problem?

pjmlp 5y ago
Borland C++ for MS-DOS used pre-processor macros in BIDS 1.0, while BIDS 2.0 replaced that hack with templates. In 2002, Visual Studio T4 was used for generating .NET code shortly after it was introduced. In 2005, Eclipse EMF was used for generating Java code, eventually Java 5 made that unnecessary. As you see, that is a path well known for the last 30 years. Eagerly waiting for Go 1.18, even with CLU like generics.
- kubb 5y ago
  The funny thing is that in 30 years there will be a new generation of people convinced that nobody needs generics because they happened not to need them in their command line tool replacing a bash script that has grown too large for comfort.
  - pjmlp 5y ago
    Sadly I have been around long enough to agree with your prophecy turning into reality.