Generics enabled by default in Go tip • Hacker News Board

Re: Generics enabled by default in Go tip

#41

Post by vorpalhex » Sat, Aug 21, 2021, 4:47 AM UTC

nerdwaller wrote: post #35

silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

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…

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.

Re: Generics enabled by default in Go tip

#42

Post by bigdubs » Sat, Aug 21, 2021, 4:49 AM UTC

silisili wrote: post #37

tedunangst wrote: post #34

Every HN thread about go: go is useless because it lacks generics. Go adds generics. HN thread: I don't want this. Good case study about the people drawn to comment on a topic.

Or good case study of squeaky wheels. I never wanted generics. I never thought to spam the development lists about how much I liked how things were going.

a couple high profile projects (k8s) needed generics, there are limited use cases outlined in the planning docs that detail the holes in the language they're filling, it wasn't just squeaky wheels.

Re: Generics enabled by default in Go tip

#43

Post by brundolf » Sat, Aug 21, 2021, 4:50 AM UTC

I've never used Go, and from the outside I take a lot of issues with its design choices.

But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to pay attention to.

One thing I'm curious about: user-defined generics I can see going without, but the core language and standard library surely need to have them. How does that work in practice? Is there a syntax for using them and just not one for creating them? How are they defined in standard library code?

Re: Generics enabled by default in Go tip

#44

Post by jshen » Sat, Aug 21, 2021, 4:50 AM UTC

leshow wrote: post #38

Taek wrote: post #21

Earlier quoted context omitted.

Find a different way to solve the problem. I've written close to half a million lines of code in Go and the lack of generics has been a pain point in maybe 1% of that? Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be. If you really need generic structures you can use the interface type but generally there's a simpler solution that doesn't require generics.

It's not as if it's a niche problem requiring a niche solution though. The problem is "how do I write my own data structures" and to the best of my knowledge Go's answer is: copy-paste everything and edit for each concrete type, use code gen, or pay runtime cost for interfaces. All of those solutions seem more complex than just having a type parameter.

They seem more complex compared to a type parameter when you are only thinking about this narrow situation. However, generics are not limited to this narrow situation and will cause complexity far beyond what you are imagining.

Having said that, I honestly don’t know if generics are a net positive or not. What I can say is that go is one of the few languages where I can jump into an arbitrary go code base and make sense of it relatively easily. Risking that is a scary proposition for me.

Re: Generics enabled by default in Go tip

#45

Post by jshen » Sat, Aug 21, 2021, 4:52 AM UTC

tengbretson wrote: post #31

Taek wrote: post #21

Earlier quoted context omitted.

Find a different way to solve the problem. I've written close to half a million lines of code in Go and the lack of generics has been a pain point in maybe 1% of that? Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be. If you really need generic structures you can use the interface type but generally there's a simpler solution that doesn't require generics.

Maybe you could have gotten that work done with fewer than 500,000 loc if you used a language with a better feature set.

And it would have been far harder to read for those new to the generic code base. Complex abstractions make people feel smart, they rarely make code easier to understand or maintain.

Re: Generics enabled by default in Go tip

#46

Post by barsonme » Sat, Aug 21, 2021, 4:53 AM UTC

aptenoforst wrote: post #20

silisili wrote: post #9

Not to be contrary for its sake, but I'll say this is one change I'm really not happy about. I feel like it's a change to placate many, while driving a lesser amount away. Which is fine, but still feels like the end of something, as I am one of the aforementioned 'lesser.' As for why...I love above most the simplicity and readability of Go. Any change which encroaches that, which this does, is a net negative to me.

If anything generics will make go code simpler. No more copy pasting everywhere and the possibility of making useful collection methods like map, filter and reduce.

More concise, yes. Simpler? Maybe[0].

And for the record, I'm mostly in favor of adding generics to Go.

[0]: https://talks.golang.org/2015/simplicity-is-complicated.slid...

Re: Generics enabled by default in Go tip

#47

Post by silisili » Sat, Aug 21, 2021, 4:53 AM UTC

deanCommie wrote: post #39

silisili wrote: post #22

Earlier quoted context omitted.

You don't write singly linked lists of arbitrary data :). In my 20+ years of development, I've definitely realized everyone's brains and approaches work differently.

You do if you want your language to have a reusable Linked List data structure so that everyone doesn't have to re-implement their own version of it for each content type.

There are languages that do this already though. Use Python. Reusable everything, just wait for exceptions.

I've spent time in C, Python, Go, Js, and some lesser known languages. I was really big into Python. Go seemed restrictive at first, but was immensely more safe and predictable.

Re: Generics enabled by default in Go tip

#48

Post by jshen » Sat, Aug 21, 2021, 4:54 AM UTC

vorpalhex wrote: post #41

nerdwaller wrote: post #35

Earlier quoted context omitted.

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…

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…

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.

Re: Generics enabled by default in Go tip

#49

Post by [deleted] » Sat, Aug 21, 2021, 4:56 AM UTC

leshow wrote: post #38

Taek wrote: post #21

Earlier quoted context omitted.

Find a different way to solve the problem. I've written close to half a million lines of code in Go and the lack of generics has been a pain point in maybe 1% of that? Usually, if you are thinking about generics you are reaching for abstraction when you don't need to be. If you really need generic structures you can use the interface type but generally there's a simpler solution that doesn't require generics.

It's not as if it's a niche problem requiring a niche solution though. The problem is "how do I write my own data structures" and to the best of my knowledge Go's answer is: copy-paste everything and edit for each concrete type, use code gen, or pay runtime cost for interfaces. All of those solutions seem more complex than just having a type parameter.

[deleted]

Re: Generics enabled by default in Go tip

#50

Post by systemvoltage » Sat, Aug 21, 2021, 4:57 AM UTC

tptacek wrote: post #23

puddingforears wrote: post #17

Earlier quoted context omitted.

How would you write a singly linked list who’s contents are arbitrary? What if you were to map a function over it? Say you want to use this data structure with third-party objects? How do you do that right now?

You wouldn't. Everybody goes into Go thinking that's absurdly confining. Some significant subset of Go programmers learn that they instead find it liberating. Programming is programming; you have an overwhelming number of degrees of freedom no matter what language you work in. It sometimes turns out that taking some of those degrees out of the language makes it easier to focus them on your problem domain.

This is one of the best definitions of 'minimalism' I've seen.