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

251–260 of 273 posts

Re: A Proposal for Adding Generics to Go

#251

Post by masklinn »

brundolf wrote: post #187
coddle-hark wrote: post #185

Earlier quoted context omitted.

It's a real pain in the ass not having generics any time you're working with algorithms and data structures. Linked lists? Graphs? Trees? Go is generally quite nice to work with but it implementing these basic structures again and again with different underlying data types makes me feel like I'm writing Java. Which is ironic because, you know, Java has generics.

I think the idea is that these fundamentals could/should be supplied by the standard library Ironically, despite all their differences, Rust actually has a similar situation: it's really hard to write the fundamental data-structures in Rust, so they've put a focus on having really good standard-library implementations and people are generally content using those (in Rust's case it's because the borrow-checker makes p…

> I think the idea is that these fundamentals could/should be supplied by the standard library

There is basically no limit to the number of data structures possible, nor to the possible implementation details of most of them, all of which can be relevant to the situation at hand.

The stdlib can hardly be expected to implement them all.

Re: A Proposal for Adding Generics to Go

#252

Post by dragonwriter »

brundolf wrote: post #187
coddle-hark wrote: post #185

Earlier quoted context omitted.

It's a real pain in the ass not having generics any time you're working with algorithms and data structures. Linked lists? Graphs? Trees? Go is generally quite nice to work with but it implementing these basic structures again and again with different underlying data types makes me feel like I'm writing Java. Which is ironic because, you know, Java has generics.

I think the idea is that these fundamentals could/should be supplied by the standard library Ironically, despite all their differences, Rust actually has a similar situation: it's really hard to write the fundamental data-structures in Rust, so they've put a focus on having really good standard-library implementations and people are generally content using those (in Rust's case it's because the borrow-checker makes p…

> I think the idea is that these fundamentals could/should be supplied by the standard library

Data structures generally need to be parameterized on the contained types of you don't want to waste the effort of even having a static type system, which makes it impossible to do this right without generics

Re: A Proposal for Adding Generics to Go

#253

Post by fileeditview »

masklinn wrote: post #250
majewsky wrote: post #192

Earlier quoted context omitted.

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

Wrong. The whole point of this construct is that in Go maps return default values for keys that do not exist. The default value for bool is false.

Re: A Proposal for Adding Generics to Go

#254

Post by alkonaut »

uluyol wrote: post #229
alkonaut wrote: post #150

Finally. Hope it gets approved. It's strange that they don't consider Print[T](x T) instead of Print[T any](t T). The "any" could just be omitted without loss of anything. Especially since repeated types with the same constraints indeed DO omit it! Print2[T1, T2 any]

The any is required to avoid a syntactic ambiguity. It was that or use the "type" keyword as in Print[type T] / Print[type T1, T2 Constraint]. The question of what the syntax should look like has been beaten to death.

There is ambiguity in Print[T](t T)? What different things could T represent there?

Re: A Proposal for Adding Generics to Go

#255

Post by bierjunge »

glouwbug wrote: post #243
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.

Eh, even C supports clean templated type safe containers: https://www.github.com/glouw/ctl Why Go is so far behind is behind me

There is a big difference here. The draft is about adding generics to the Go stdlib, not about if it's possible. Is it even possible? Yeah, there are some implementation (e.g. https://github.com/cheekybits/genny). So Go is not "far behind" C, which also does not have generics (or did I miss something in C11/C17?).

Re: A Proposal for Adding Generics to Go

#256

Post by Tainnor »

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

> Doing the same in Kotlin, laptop freezes, android studio freeze, time to get a coffee

I work in Kotlin every day and my laptop never freezes.

I'm sure compile times are shorter in Go (after all, that's one of Go's main selling points). But compiling Kotlin code doesn't seem to be a huge bottleneck in my experience (and I have worked in some other languages that had truly atrocious compile times cough Swift cough). In fact, it usually takes longer for Spring to boot than for the Kotlin code to compile.

Re: A Proposal for Adding Generics to Go

#257

Post by atom_arranger »

johnnycerberus wrote: post #71
jacques_chester wrote: post #25

Earlier quoted context omitted.

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…

Java, Go, OCaml, Typescript (>=3.9) are in their own league when it comes to compilation speed.

  1. OCaml
  2. Go
  3. Java
  ...
  999. TypeScript (any version)
The TypeScript team should consider rewriting the type checker in Rust or Go IMO. It's free, they can do what they want, but the performance is really not good (compared to what it could be) and affects a lot of people.

Re: A Proposal for Adding Generics to Go

#258

Post by simiones »

praptak wrote: post #248
anothernewdude wrote: post #247

Earlier quoted context omitted.

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.

The only difference between Go and Java 1.4 in terms of collections is that Go has a generic map type, which Java didn't. Java 1.4 still had generic arrays, just like Go. In fact, it was a little easier to program with generic arrays in Java vs Go (but also less safe) because in Java a subtype[] can be passed to a function which takes a supertype[] (arrays are covariant).

Re: A Proposal for Adding Generics to Go

#259

Post by simiones »

masklinn wrote: post #77
jjtheblunt wrote: post #55

Earlier quoted context omitted.

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

> isn't generic Sets easily implemented with map being already generic? Since Go has neither generic functions nor generic typedefs you can't implement a Set with a generic key type on top of map, you have to reimplement all the set operations for each key type you use.

In addition to that, map[T]bool only works if T is one of the few types that Go can check for equality automatically. You can't define a custom equality (+hash) function for your type and use it with the built-in map.

Re: A Proposal for Adding Generics to Go

#260

Post by brundolf »

masklinn wrote: post #251
brundolf wrote: post #187

Earlier quoted context omitted.

I think the idea is that these fundamentals could/should be supplied by the standard library Ironically, despite all their differences, Rust actually has a similar situation: it's really hard to write the fundamental data-structures in Rust, so they've put a focus on having really good standard-library implementations and people are generally content using those (in Rust's case it's because the borrow-checker makes p…

> I think the idea is that these fundamentals could/should be supplied by the standard library There is basically no limit to the number of data structures possible, nor to the possible implementation details of most of them, all of which can be relevant to the situation at hand. The stdlib can hardly be expected to implement them all.

If they're very specific to the situation at hand, they're much less likely to need to be generic. The GP explicitly mentioned "Linked Lists" and "Trees". You don't need to be writing your own linked-list or (basic) tree from scratch.
Post reply on HN