Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Proposal for Adding Generics to Go

blog.golang.org

Post reply on HN
Print view View original

51–60 of 273 posts

Re: A Proposal for Adding Generics to Go

#51

Post by lkramer »

thomascgalvin wrote: post #44
lkramer wrote: post #26

Earlier quoted context omitted.

This is not the first time I argue this case, but I would go a step further and say that not having generics is feature of Go. There are plenty of languages out there with Generics. I use several of them. I use Go when that suits me, and it's typically for cases where high readability trumps doing a lot of magic with generics. I think only once or twice have I thought to myself, "this would have been better with Gene…

Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code. Having `Set ` and `Set ` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace. You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two…

Can you give a real world example that couldn't be solved with interfaces?

The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

Re: A Proposal for Adding Generics to Go

#53

Post by candiddevmike »

It's too bad this is targeting end of year, I have so many applications for this--test assertions, http controllers, SQL--this will remove a lot of duplicate code. I also think it will expand use cases for Go, especially in the UX area where you have to implement duplicative getters and setters.

Re: A Proposal for Adding Generics to Go

#54

Post by candiddevmike »

lkramer wrote: post #51
thomascgalvin wrote: post #44

Earlier quoted context omitted.

Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code. Having `Set ` and `Set ` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace. You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two…

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

I think you're looking at it wrong. You can absolutely solve it with interfaces, the problem is those interface methods are identical, so it's duplicative.

Re: A Proposal for Adding Generics to Go

#55

Post by jjtheblunt »

egeozcan wrote: post #16
tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

I actually just need generic Sets. Generic map/reduce on slices wouldn't hurt too. OTOH, it's 2021 and look at what we are wishing. My love/hate relationship with golang is like the one I have with Apple.

isn't generic Sets easily implemented with map being already generic?

Re: A Proposal for Adding Generics to Go

#56

Post by chowells »

lkramer wrote: post #51
thomascgalvin wrote: post #44

Earlier quoted context omitted.

Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code. Having `Set ` and `Set ` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace. You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two…

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

You can't use interfaces to prevent inserting values of the wrong types into a set. When you view the purpose of types as preventing bugs, that seems like a giant missing feature.

Re: A Proposal for Adding Generics to Go

#57

Post by dhagz »

jacques_chester wrote: post #25
tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

If we're dealing in anecdata, mine is that "Go compiles fast!" is true right up until something in your dependency tree hauls in kubernetes repos, perhaps multiple times. Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. Kotlin does compile much slower than I would like, but at least I only haul in one version of libraries and 0% of it is generated code. Java is basically insta…

I'm currently working on a project that depends on the k8s APIs and I haven't noticed ballooning compile times.

I'm only pulling in k8s.io/api, k8s.io/apimachinery, and k8s.io/go-client though.

Re: A Proposal for Adding Generics to Go

#58

Post by fileeditview »

jjtheblunt wrote: post #55
egeozcan wrote: post #16

Earlier quoted context omitted.

I actually just need generic Sets. Generic map/reduce on slices wouldn't hurt too. OTOH, it's 2021 and look at what we are wishing. My love/hate relationship with golang is like the one I have with Apple.

isn't generic Sets easily implemented with map being already generic?

Yes and that's probably why there is no set in the go std lib. You just can use struct{}{} as (empty) value in a map.

Re: A Proposal for Adding Generics to Go

#59

Post by coldtea »

jjtheblunt wrote: post #55
egeozcan wrote: post #16

Earlier quoted context omitted.

I actually just need generic Sets. Generic map/reduce on slices wouldn't hurt too. OTOH, it's 2021 and look at what we are wishing. My love/hate relationship with golang is like the one I have with Apple.

isn't generic Sets easily implemented with map being already generic?

Not if you need to implement set operations (union, intersect, etc.) on your own each time.

Generic maps as sets are only ok for membership checks.

Re: A Proposal for Adding Generics to Go

#60

Post by coldtea »

lkramer wrote: post #51
thomascgalvin wrote: post #44

Earlier quoted context omitted.

Generics aren't magic, and they aren't Turing complete, like C++ templates. They're just a way to avoid copy-pasting code. Having `Set ` and `Set ` is far more readable than `class FooSet` and `class BarSet`, where the code is exactly the same aside from a search-and-replace. You also run into issues where someone finds a bug in `FooSet`, but doesn't know `BarSet` exists, and forgets to patch both. Now, you have two…

Can you give a real world example that couldn't be solved with interfaces? The only real cases I can see is creating new data structures, (for instance if you wanted to create your own map type).

>The only real cases I can see is creating new data structures

Half of programming is creating new data structures.

The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.

Post reply on HN