4 ms·

I fully agree, after writing go for the last 7 years. I recognize that generics solve some problems, but there’s a cost in doing so. In that period I’ve had onl

I fully agree, after writing go for the last 7 years. I recognize that generics solve some problems, but there’s a cost in doing so. In that period I’ve had only a few cases where I wish I was back in a language with this feature (Java being my previous typed language), however most of the time the interface with an application specific data model was more than sufficient. Obviously you need to wrap that abstraction for typesafe code, but that’s pretty trivial.

vorpalhex 5y ago
Without generics, I have seen terrible and unreadable golang code. There is no tool that can not be mis-used. Generics are adding a tool to the toolbox. They can be used well or they can be mis-used. I recently wrote a gui app in Golang using Fyne and I really wish I'd had generics for some of the UI handling - instead I ended up having to write some really ugly and not simple code to handle the case. The end result was worse and less-simple than if I had been able to use generics.
- jshen 5y ago
  Can you give an example of terrible unreadable go code due to a lack of generics? I’ve grown to love go because it’s one of the few languages where I can jump into a new code base and relatively easily understand what is going on.
  - kmm01 5y ago
    Because you will already have seen that precise piece of code in a thousand other contexts?
  - dmitriid 5y ago
    > Can you give an example of terrible unreadable go code due to a lack of generic https://news.ycombinator.com/item?id=28254411 https://news.ycombinator.com/item?id=28254411 The "solution" to this is copy-pasted boilerplate code with casting for every call.
- theshrike79 5y ago
  I have seen terrible and unreadable generic code, people building abstractions just for the sake of abstractions. Hello-world level projects with 20 class deep hierarchies of generic classes, just to make it "generic" in case you need it later.
  - doctor_eval 5y ago
    I agree. It’s true for all languages. I once had to untangle a small Java app that had about five packages with two classes per package (I refactored it into a single package). Some people will abuse generics, no doubt, just like my colleague abused packages. But Go has such a strong culture around idiomatic code that I’m not too worried that generics are the end of the world. In fact, I don’t like keywords like “append” and I’m hopeful generics will replace them. TBH I was more upset about the Go 1.17 ability to panic during a type conversion from slice to array pointer. That one really grates my gears.

vorpalhex 5y ago

Without generics, I have seen terrible and unreadable golang code. There is no tool that can not be mis-used. Generics are adding a tool to the toolbox. They can be used well or they can be mis-used. I recently wrote a gui app in Golang using Fyne and I really wish I'd had generics for some of the UI handling - instead I ended up having to write some really ugly and not simple code to handle the case. The end result was worse and less-simple than if I had been able to use generics.

jshen 5y ago
Can you give an example of terrible unreadable go code due to a lack of generics? I’ve grown to love go because it’s one of the few languages where I can jump into a new code base and relatively easily understand what is going on.
- kmm01 5y ago
  Because you will already have seen that precise piece of code in a thousand other contexts?
- dmitriid 5y ago
  > Can you give an example of terrible unreadable go code due to a lack of generic https://news.ycombinator.com/item?id=28254411 https://news.ycombinator.com/item?id=28254411 The "solution" to this is copy-pasted boilerplate code with casting for every call.
theshrike79 5y ago
I have seen terrible and unreadable generic code, people building abstractions just for the sake of abstractions. Hello-world level projects with 20 class deep hierarchies of generic classes, just to make it "generic" in case you need it later.
- doctor_eval 5y ago
  I agree. It’s true for all languages. I once had to untangle a small Java app that had about five packages with two classes per package (I refactored it into a single package). Some people will abuse generics, no doubt, just like my colleague abused packages. But Go has such a strong culture around idiomatic code that I’m not too worried that generics are the end of the world. In fact, I don’t like keywords like “append” and I’m hopeful generics will replace them. TBH I was more upset about the Go 1.17 ability to panic during a type conversion from slice to array pointer. That one really grates my gears.