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

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

91–100 of 439 posts

Re: Proposal: Go should have generics

#91

Post by fauigerzigerk »

madawan wrote: post #69
microtonal wrote: post #66

Earlier quoted context omitted.

First of all, generics is hardly DRY to its extreme. I think that everyone agrees that copying e.g. a balancing red-black tree implementation just to specialize it for another value type is a pretty bad idea. So then you either end up with some kind of runtime polymorphism or parametric polymorphism. Some Go users argue that runtime polymorphism is enough, but you often run into cases where you have a func frobber(s…

The way I work is, I make an interface{} red-black-tree, and then when I need to store things in it I create functions around it. Suppose I'm storing Tiles in a Level: the Level struct will contain a (private) RedBlackTree and I'll define GetTile(Pos) Tile and PutTile(Pos, Tile) on Level which do the casting to and from interface{}. I still have type safety since I cannot put/get anything but Tiles in the RedBlackTre…

You can only do that in places where you don't care about memory usage at all.

Re: Proposal: Go should have generics

#92

Post by reycharles »

bigdubs wrote: post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

Rob Pike's repository 'filter'[0] contains implementations of map ("Apply"), filter ("Choose", I believe), and fold/reduce ("Reduce"). The code is an ugly mess, and the implementation shows that he probably hasn't used any of these standard functions in other languages (see the weird permutations of 'filter' in apply.go, or my patch for his fold/reduce implementation[1]). The README is also quite arrogant, IMO.

> I wanted to see how hard it was to implement this sort of thing in Go, with as nice an API as I could manage. It wasn't hard.

> Having written it a couple of years ago, I haven't had occasion to use it once. Instead, I just use "for" loops.

> You shouldn't use it either.

[0]: https://github.com/robpike/filter/

[1]: https://github.com/robpike/filter/pull/1

Re: Proposal: Go should have generics

#93

Post by jhoechtl »

bigdubs wrote: post #7

After watching Rob Pike's Go Proverbs talk I am pretty convinced generics, as much as some would want it, will never happen. He proselytizes "just copy a little code here and there" quite clearly, which is at odds with the complexity that generics would add.

Given the Autor is Ian Lance Taylor I personally do not think that there is no chance for implementation

Re: Proposal: Go should have generics

#94

Post by Loic »

mattlondon wrote: post #68

I can feel the pain on the Sort issue. I've personally found sorting annoying in Go - I had a bunch of structs representing data entities from a database that all had the same field and I wanted to be able to sort them by this field. Seemed like a LOT of work (basically implementing the same sort that was 99% identical for every struct) or use weird reflection-workarounds to get this to happen. In Java I would not ev…

I had the same feeling first. But practically in my code, I found that ok, you need to copy/paste a bit first but then if it works it stays there, you are not "sorting" new kind of "types" every day. The time spent on coding is way more "around" the algorithms than "within" them.

I suppose that we will see more and more code generators which will practically remove the need of generics. We already use them without complaining for serialization in JSON/Protocolbuffer/etc...

Re: Proposal: Go should have generics

#95

Post by Ericson2314 »

enneff wrote: post #87
Ericson2314 wrote: post #84

Earlier quoted context omitted.

I don't want to start a flame war, but parametric polymorphism has been exhaustively studied for decades . Any technical difficulties of bolting it on Go at this stage probably stem from uncertainty about Go's existing semantics rather than the new feature itself. So I hope there are non-technical reasons that have led to the features delay.

That's precisely it. We don't want to "bolt on" any feature to Go. The features should interact nicely. Language design is all about tradeoffs like this. There's a lot of information out there about Go's design process and goals. If you read up on it (and the proposals that are the subject of this thread) you can see why parametric polymorphism isn't something that you can just shove into the language.

My point is that if Go was properly formalized as it should have been all along, this would be a lot easier.

These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.

Re: Proposal: Go should have generics

#96

Post by enneff »

Ericson2314 wrote: post #95
enneff wrote: post #87

Earlier quoted context omitted.

That's precisely it. We don't want to "bolt on" any feature to Go. The features should interact nicely. Language design is all about tradeoffs like this. There's a lot of information out there about Go's design process and goals. If you read up on it (and the proposals that are the subject of this thread) you can see why parametric polymorphism isn't something that you can just shove into the language.

My point is that if Go was properly formalized as it should have been all along, this would be a lot easier. These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.

Will keep that in mind. Thanks!

Re: Proposal: Go should have generics

#98

Post by isuckatcoding »

This makes me wonder if this has happened before in another language. I can totally imagine 10 years ago someone saying "oh we'll never need that in PHP" and voila 10 years later you've now got feature X in PHP. Any of you wise old timers want to share such examples? Does history keep repeating itself with these sorts of things?

Re: Proposal: Go should have generics

#99

Post by kqr »

isuckatcoding wrote: post #98

This makes me wonder if this has happened before in another language. I can totally imagine 10 years ago someone saying "oh we'll never need that in PHP" and voila 10 years later you've now got feature X in PHP. Any of you wise old timers want to share such examples? Does history keep repeating itself with these sorts of things?

Generics in Java? Anonymous functions in Java? Most everything in Java?

Re: Proposal: Go should have generics

#100

Post by Ericson2314 »

enneff wrote: post #96
Ericson2314 wrote: post #95

Earlier quoted context omitted.

My point is that if Go was properly formalized as it should have been all along, this would be a lot easier. These past proposals are needlessly informal---running the risk of missing any important details. For future proposals, I highly recommend the use of judgements / a sequent calculus to formally specify the type system.

Will keep that in mind. Thanks!

Good luck!
Post reply on HN