Live data from Hacker News

Generics enabled by default in Go tip

go-review.googlesource.com

61–70 of 378 posts

Re: Generics enabled by default in Go tip

#61
post #23

Earlier quoted context omitted.

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.

While it's true that some find it liberating, a large number don't — personally, I've written a fair amount of production Go code and found it unnecessarily verbose and repetitive in ways that generics would've helped. I imagine some of this is based on problem domain; if you're writing a web application for example, maybe you don't really need generics much. After all, how often do you need a function that logs in a…

You say "verbose and repetitive", I say "easy to read without any surprises".

The verbose patterns (if err!= nil for example) make the code predictable to read, you notice the code smell of missing error handling really fast.

Re: Generics enabled by default in Go tip

#62
post #44
post #38

Earlier quoted context omitted.

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 se…

This can be said for any programming language and any community: there will always be bad code written by someone.

Generic data structures are provided in many programming languages and there are many people that are very experienced in writing some of these, so being able to reuse, it's precious.

In general the lack of generic price surfaces when you write libraries, not applicative code. But libraries are a big portion of a codebase.

Re: Generics enabled by default in Go tip

#63
post #45

Earlier quoted context omitted.

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.

Optimizing for people that are new to a codebase seems like a mistake to me: onboarding costs are relatively minimal and finite (per developer) whereas maintenance costs have no fixed bound: if generics let you exclude invalid states by design (and they do: this is one of the biggest advantages of parametric polymorphism vs. interfaces), they will be useful for keeping maintenance costs under control.

Re: Generics enabled by default in Go tip

#64
post #45

Earlier quoted context omitted.

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.

How is a generic data structure a COMPLEX ABSTRACTION?

They are complex. I’m guessing you haven’t thought about them much beyond the trivial use cases.

Re: Generics enabled by default in Go tip

#65
post #23

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.

Yeah, that's why Kubernetes had to develop code generators. So focused.

Re: Generics enabled by default in Go tip

#66
post #30
post #26

Not excited about this feature, I guess we'll see how frequently it shows up in unwanted places. Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. Very skeptical, but the go devs have given me plenty of pleasant surprises before, maybe we get another one here.

Generics in C++ really damage the readability of the code sometimes, maybe the go devs have found a better way. The culture might help. I think generics in Java are not overused -- partly because they are not so powerful and partly because Java, similar to Go, did not have generics for a long time.

C++ also went a long time without generics, and even when support started to appear it was a separate code generation step, requiring even more time before we saw first-class compiler support.

Powerful, though.

Re: Generics enabled by default in Go tip

#67
post #53
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 i wanted or needed generics i would use another language. I have been able to write great code without them for 5 years now though. But now i get to defend my codebases from the unneeded introduction of them from largely developers who think they are too smart.

Same here. But I think it's more laziness than 'too smart.'

I like to liken it to house construction. Imagine if a number of people demanded that natural gas and water be combined. Why do I have to make two separate pipes? They even look the same!

Re: Generics enabled by default in Go tip

#68
post #45

Earlier quoted context omitted.

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.

How is a generic data structure a COMPLEX ABSTRACTION?

If people would stick to common generic data structures (like a map/list that can handle any datatype), i'd be fine with abstractions.

But some people have a tendency to play code golf with their codebases.

I have, for example, encountered a "generic data structure" that looked like a normal linked list on the surface. BUT, it actually sorted the largest three items in the first 3 cells and the average in the 4th.

That was multiple days of work wasted because someone decided to be cute with their data structures. And that wasn't even the only one of such "generic" monstrosities in the code.

Re: Generics enabled by default in Go tip

#69

Earlier quoted context omitted.

Singly linked lists are something from CS1 where you learn about data structures. You rarely use them in practice. In most cases slices and maps do the job fine.

They also have absolutely terrible performance due to poor cache locality and putting pressure on GC

Source?

Re: Generics enabled by default in Go tip

#70
post #45

Earlier quoted context omitted.

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.

Optimizing for people that are new to a codebase seems like a mistake to me: onboarding costs are relatively minimal and finite (per developer) whereas maintenance costs have no fixed bound: if generics let you exclude invalid states by design (and they do: this is one of the biggest advantages of parametric polymorphism vs. interfaces), they will be useful for keeping maintenance costs under control.

I’m guessing you like Haskell and similar languages, because that’s the natural conclusion to your line of reasoning.

I don’t agree with you, but I could be wrong. There are plenty of languages that are aligned with your point of view. I like go because it was going a different direction, and I hope that doesn’t change. You can use Haskell, scala, typescript, etc to get what you are looking for.

Post reply on HN