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

241–250 of 273 posts

Re: A Proposal for Adding Generics to Go

#241

Post by arp242 »

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).

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

There are none, you can always work around them, with the only downside is that you'll move some potential compile-time errors to runtime errors.

But that's the wrong conversation to be having; we could also say "why do we need floats? Everything can be solved with ints too", which is true, but also a lot of work and a poor trade-off. Similar arguments exist for many language features.

So it's a question of trade-offs: how much time will this save people? Will it reduce faults? And what are the costs of adding this? And how do they balance?

Re: A Proposal for Adding Generics to Go

#242

Post by cannabis_sam »

uncledave wrote: post #181
travv0 wrote: post #172

Earlier quoted context omitted.

> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. What does any of that have to do with generics?

Well the generic programming model tends to favour using light weight abstract data structures instead of well defined types. Those abstractions are by nature leaky so many internal concerns leak out of abstraction boundaries into the caller and give them one hell of a bad time.

> Those abstractions are by nature leaky

Do you have any examples?

Re: A Proposal for Adding Generics to Go

#243

Post by glouwbug »

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.

Eh, even C supports clean templated type safe containers:

https://www.github.com/glouw/ctl

Why Go is so far behind is behind me

Re: A Proposal for Adding Generics to Go

#244

Post by _QCanaria_ »

kitkat_new wrote: post #8

I hope at some point they manage to add it. I, however, discovered Rust in the meanwhile. It has generics. And it is not too complex either and has quite a few other bonuses.

Here we go again ...

I'd be happy if Rust evangelists would stop trying to steal every post on other languages to praise the superiority of Rust.

I won't go into details on how to choose the right tool for the job or the many very relevant disadvantages of Rust in the real world of getting stuff into production compared to Java, Go or .NET, but if Rust was so superior: Why is it still a niche language after reading for years how superior it is?

Re: A Proposal for Adding Generics to Go

#245

Post by _QCanaria_ »

The carefulness of the Go team when introducing new features is remarkable.

After many years chasing the newest, shiniest and best tools I can't appreciate stability and a large and useful standard lib enough. I finally understood the importance of the boring stack.

I don't need generics in Go, but I'm happy they are coming. Especially for collection methods.

Re: A Proposal for Adding Generics to Go

#246

Post by smokey_circles »

Generics are awful. They solve no problem in the domain space, only the developer space.

Which then creates the problem of developers who insist on writing infinitely extensible generics with indecipherable bounds.

Just repeat code. You'll be fine.

If you find yourself repeating a LOT of code because Go does not support generics, maybe stop and think about your design. Putting generics in as an escape hatch will do you more than good, guaranteed

Re: A Proposal for Adding Generics to Go

#247

Post by anothernewdude »

praptak wrote: post #201
stickfigure wrote: post #99

Earlier quoted context omitted.

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

Go (without generics) is not Java 1.4. Go's built-in collections are actually generic and Java's generic-less awkwardness was mostly about collections.

I know, right? In Java 1.4 you cast to Object, in Go you cast to interface{}. Totally different.

Re: A Proposal for Adding Generics to Go

#248

Post by praptak »

anothernewdude wrote: post #247
praptak wrote: post #201

Earlier quoted context omitted.

Go (without generics) is not Java 1.4. Go's built-in collections are actually generic and Java's generic-less awkwardness was mostly about collections.

I know, right? In Java 1.4 you cast to Object, in Go you cast to interface{}. Totally different.

Most of the casting in Java 1.4 was from collections of Object. In Go the collections are typed, so the casting is confined to some very specialized pieces of code.

Re: A Proposal for Adding Generics to Go

#249

Post by masklinn »

swirepe wrote: post #232
marcus_holmes wrote: post #222

Earlier quoted context omitted.

Agreed. I'll be banning generics from any code I have control over unless there's a very good reason for it. I saw too much of this crap in C#, and ran from it screaming.

Say you need a binary heap to hold some customer records, and another binary heap to store some orders. How many times do you implement a binary heap?

Apparently their answer is “five times”.

Re: A Proposal for Adding Generics to Go

#250

Post by masklinn »

majewsky wrote: post #192
jrockway wrote: post #122

Earlier quoted context omitted.

A map[T]bool has 3 states for every key; absent, true, and false. A map[t]struct{} has 2 states for every key; absent, and present. People new to Go tend to pick map[T]bool or map[T]int because they're used to using bools and ints throughout their code, but struct{} is the correct value type for sets. (That is not to say that a counting set, map[T]int is useless, however. If you need that, use that!)

I usually use map[T]bool because if _, ok := wasTouched[thing]; !ok { touch(thing) wasTouched[thing] = struct{}{} } is way uglier than if !wasTouched[thing] { touch(thing) wasTouched[thing] = true }

That doesn’t actually work unless you first fill all possible values with `false`.
Post reply on HN