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

121–130 of 439 posts

Re: Proposal: Go should have generics

#121

Post by coldtea »

Loic wrote: post #94
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 co…

>you are not "sorting" new kind of "types" every day

You'd be surprised.

Re: Proposal: Go should have generics

#122

Post by ngrilly »

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.

Does you critic applies to Rust as well which, as far as I know, is not formalized either?

Are OCaml or Haskell propery formalized?

Re: Proposal: Go should have generics

#123

Post by idobai »

duaneb wrote: post #18
xiaopingguo wrote: post #3

Why not just fork the language? Why does one language need to do all the things?

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no u…

> EDIT: of course this is good; such a language would be beyond nightmarish. By which i mean c++ or scala.

Then go and compare the same code in go and Scala and see which is more "nightmarish". You see Scala as a complex language because you need to learn something before you use it while go is almost the opposite - you may get it in an afternoon and create repetitive, boilerplatish and unmaintanable mess.

Re: Proposal: Go should have generics

#124

Post by hathym »

inglor wrote: post #110
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…

This is stupidly easy with http://dl.acm.org/citation.cfm?id=2738008 - I opened an issue for considering something like this for go https://github.com/golang/go/issues/15295 hopefully I didn't err in posting it :)

are you really posting a paid article on HN?

Re: Proposal: Go should have generics

#125

Post by tazjin »

reycharles wrote: post #92
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 w…

This is what people mean when they say that Go has disregarded everything we learned in the programming language community in the last decades.

Sure, some people are productive in it and that's fine - but for those of us who have worked in better languages taking the step down is unattractive.

Re: Proposal: Go should have generics

#127

Post by coldtea »

As long as programmers that are comfortable with (and prefer) 30+/40+ year old PL paradigms are at the helm of Go's design, it's not very likely the language will grow Generics.

To paraphrase Max Plank:

"A new language-level feature does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."

Re: Proposal: Go should have generics

#128

Post by junke »

xiaq wrote: post #77
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…

Write a code generator. That's the best solution at this moment.

You might be right, this is the best solution in Go at this moment, but that's a local optimum. You don't have to solve this kind of problems in many other languages.

The generator given as an example in the official blog [0] is called "stringer". It is made of 639 lines [1] mixing ast parsing/traversing and printf statements. If this is what I am supposed to write then of course copy-pasting becomes a pragmatic alternative.

[0] https://blog.golang.org/generate

[1] https://raw.githubusercontent.com/golang/tools/master/cmd/st...

Re: Proposal: Go should have generics

#129

Post by coldtea »

f2f wrote: post #2

"The intent is not to add generics to Go at this time, but rather to show people what a complete proposal would look like. We hope this will be of help to anyone proposing similar language changes in the future." This started in 2010. Hopefully an illustration that go's developers are not against generics in general, this ought to quell some of the negativity... Pick one of the four proposals you like :)

>This started in 2010. Hopefully an illustration that go's developers are not against generics in general, this ought to quell some of the negativity...

Wouldn't the fact that this started 6 years ago and gone nowhere re-enforce the negativity?

Re: Proposal: Go should have generics

#130

Post by coldtea »

ViktorasM wrote: post #24
duaneb wrote: post #18

Earlier quoted context omitted.

Generics are not "all the things". Last i checked there was still no object inheritance (in a subtype sense for interface implementations), no operator overloading, no bytecode/vm/jit, no inline asm, no macros, no pluggable gc, no call/cc, no (idiomatic) exceptions, no currying, no weak typing or implicit conversions, no way of enforcing referential transparency, no STM, no laziness, no assertions, no contracts, no u…

but having all those things go would become another C++ with a different syntax. I like the direction Go is going of "there are no options to choose", like unconfigurable fmt, or the fact that there is no way to create "exotic" implementations. However, generics would be my number #1 on the list of "maybe let's add that". Would be nice to have less "interface {}" in reusable libraries. Exceptions would be probably se…

>but having all those things go would become another C++ with a different syntax.

Haskell and CL have "all those things" and they are not "C++ with a different syntax".

I don't know why people repeat these cliches... It's not like a language can't have many features and be designed well at the same time. It just takes preparation and effort instead of ad-hoc additions (like with C++).

Post reply on HN