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

61–70 of 273 posts

Re: A Proposal for Adding Generics to Go

#61

Post by coldtea »

lkramer wrote: post #48
deskamess wrote: post #36

Earlier quoted context omitted.

The introduction of generics would not change your workflow though. You could still happily "not use it" and keep matters readable. Others who wanted it, would use it.

Mostly concerned about having to read other people's code that uses it.

If others people code uses it, then those other people deemed it useful.

So the argument for not having them now becames either:

(a) they rather not have it available, because you personally don't find it useful

(b) those using generic don't know what they're doing, and only people not using generic are smart, so it's better to not have them to prevent the clueless from being able to use them

Re: A Proposal for Adding Generics to Go

#62

Post by joshlemer »

fileeditview wrote: post #58
jjtheblunt wrote: post #55

Earlier quoted context omitted.

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.

I thought the idomatic approach was to represent sets with map[key]bool

Re: A Proposal for Adding Generics to Go

#63

Post by rowanseymour »

I rarely find myself frustrated with the lack of generics in Go and am so glad to never deal with the kind of over-engineered generic madness that is so common in Java, except...

When dealing with collections. It's maddening to have to keep duplicating basic functions like getting the keys from a map, or checking if a slice contains a given item.

Re: A Proposal for Adding Generics to Go

#64

Post by philosopher1234 »

joshlemer wrote: post #62
fileeditview wrote: post #58

Earlier quoted context omitted.

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.

I thought the idomatic approach was to represent sets with map[key]bool

The bool is meaningless, so empty struct is more clear as it contains no state.

Re: A Proposal for Adding Generics to Go

#65

Post by Animats »

Two more levels of blogs down, the actual proposal.[1] Definition:

    // Print has a type parameter T and has a single (non-type)
    // parameter s which is a slice of that type parameter.
    func Print[T any](s []T) { ... }
Call:

    Print[int]([]int{1, 2, 3})
Above, "any" is really just a synonym for "interface{}". You can have more restrictive type constraints on parameterized types by specifying other Go interfaces. This is vaguely similar to how Rust does it, and quite different from the C++ approach.

"This design does not support template metaprogramming or any other form of compile time programming."

[1] https://go.googlesource.com/proposal/+/refs/heads/master/des...

Re: A Proposal for Adding Generics to Go

#66

Post by RHSeeger »

joshlemer wrote: post #62
fileeditview wrote: post #58

Earlier quoted context omitted.

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.

I thought the idomatic approach was to represent sets with map[key]bool

As someone who finds "indicating intent in the code" an important thing, I must admit I find this concert slightly horrifying. A Map and a Set are two different things and which one you use conveys some intent as to what you mean by your code. I get that it works, but it would still make me unhappy to do.

Re: A Proposal for Adding Generics to Go

#67

Post by dilap »

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…

> Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable.

That's interesting, could you explain this more?

Context: I used to use Go a lot, but mostly haven't since Go modules, and I'm curious to know the details of the problem and why it happens.

Re: A Proposal for Adding Generics to Go

#68

Post by fanf2 »

Animats wrote: post #65

Two more levels of blogs down, the actual proposal.[1] Definition: // Print has a type parameter T and has a single (non-type) // parameter s which is a slice of that type parameter. func Print[T any](s []T) { ... } Call: Print[int]([]int{1, 2, 3}) Above, "any" is really just a synonym for "interface{}". You can have more restrictive type constraints on parameterized types by specifying other Go interfaces. This is v…

My understanding from the “Featherweight Go” paper https://arxiv.org/abs/2005.11710 is that generic types will not simply be a synonym for interface{} because the compiler will be able to monomorphize them - they do not require dynamic dispatch like interfaces.

Re: A Proposal for Adding Generics to Go

#69

Post by lights0123 »

Animats wrote: post #65

Two more levels of blogs down, the actual proposal.[1] Definition: // Print has a type parameter T and has a single (non-type) // parameter s which is a slice of that type parameter. func Print[T any](s []T) { ... } Call: Print[int]([]int{1, 2, 3}) Above, "any" is really just a synonym for "interface{}". You can have more restrictive type constraints on parameterized types by specifying other Go interfaces. This is v…

(also C++ concepts)

Re: A Proposal for Adding Generics to Go

#70

Post by dgb23 »

egeozcan wrote: post #21
skrtskrt wrote: post #14

Earlier quoted context omitted.

I like Go, but I too in the meantime have dipped my toes into Rust and it's just so much better without being that much more complex. The learning curve is real but quite a bit overstated I think.

There's this common belief that "rust is too hard", which used to be actually true, but the docs and the language itself came a long way since those times. I'd say: If you can code in C#/TS (or anything like) + go, then it only depends if you have a free weekend.

Rust has quite a few concepts you won't find in (some of) those languages like borrowing, lifetimes, traits, monomorphization, macros, type semantics around concurrency, (partial) expression based syntax, pattern matching and match guards...

However you can litter your code with unwrap and clone to reach the finish line quickly, but then you lose the two main value props of the language and likely lose performance and runtime consistency over other languages.

Post reply on HN