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

81–90 of 439 posts

Re: Proposal: Go should have generics

#81

Post by microtonal »

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…

From your description, it is not completely clear what you are ordering on, but typically in an RB tree you (at the very least) want to require some interface/function that specifies ordering and equality.

Of course, in some cases you can do casting on your interface boundaries. But in many other cases this is not possible, e.g. if you want the API to return an ordered set or map.

Re: Proposal: Go should have generics

#82

Post by fauigerzigerk »

catfest wrote: post #23
ktamura wrote: post #12

Earlier quoted context omitted.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

Memory usage and as a consequence of that excessive GC pauses. I'm not looking at any JVM language again before they introduce value types in a couple of years (maybe).

Re: Proposal: Go should have generics

#83

Post by Intermernet »

eru wrote: post #65
pcwalton wrote: post #16

Earlier quoted context omitted.

Generics are a very simple feature as implemented in, for example, SML or OCaml. They're much simpler than Go interfaces, in fact.

Generics become complicated when you have other subtype relationships, don't they? (That's why SML, OCaml and Haskell don't really do inheritance, isn't it?)

Go doesn't do inheritance either. It has type embedding, but it's not the same.

In the most recent of Ian Lance Taylor's proposals (Type parameters, 2013 [1]) he summarizes:

> The implementation description is interesting but very complicated. Is any compiler really going to implement all that? It seems likely that any initial implementation would just use macro expansion, and unclear whether it would ever move beyond that. The result would be increased compile times and code bloat.

So I'm pretty sure that the logic is acceptable, but it conflicts with Go's core goals of simplicity and compilation speed.

[1]: https://github.com/golang/proposal/blob/master/design/15292/...

Re: Proposal: Go should have generics

#84

Post by Ericson2314 »

enneff wrote: post #71
Ericson2314 wrote: post #63

Earlier quoted context omitted.

Yeah they haven't done it yet, and might still never do it, to save face. What could have been a simple 1.0 missing feature has been politicized into Go's defining feature/mistake.

There is nothing political about it, and speaking as someone on the inside it is simply ridiculous to think of it that way. What these real proposals show is that a lot of sincere effort has been spent by members of the core team writing, reviewing, and debating generics proposals over a span of multiple years. Ian only recently felt comfortable releasing them publicly, and so here they are.

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.

Re: Proposal: Go should have generics

#85

Post by enneff »

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.

Or, y'know, just copy and paste the trivial code. It should take all of 30 seconds.

Not saying that it's pretty, but it's quick and easy.

Re: Proposal: Go should have generics

#86

Post by discreteevent »

omginternets wrote: post #70
catfest wrote: post #23

Earlier quoted context omitted.

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

>you get the language simplicity And the most complex toolchain imaginable. This is what turns me off to Java, personally, but I think my case is fairly representative.

A text editor, javac and java that's what I used for a few years when I started using it. I wrote a lot of code like that. I don't see why you couldn't?

Re: Proposal: Go should have generics

#87

Post by enneff »

Ericson2314 wrote: post #84
enneff wrote: post #71

Earlier quoted context omitted.

There is nothing political about it, and speaking as someone on the inside it is simply ridiculous to think of it that way. What these real proposals show is that a lot of sincere effort has been spent by members of the core team writing, reviewing, and debating generics proposals over a span of multiple years. Ian only recently felt comfortable releasing them publicly, and so here they are.

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.

Re: Proposal: Go should have generics

#88

Post by meanary »

thegenius2000 wrote: post #79
pjmlp wrote: post #50

Earlier quoted context omitted.

If you have the money, there are lots of commercial JVMs with compilers to native code. There are quite a few open source ones, but they aren't as stable. As always, Language != Implementation.

Agreed, but remember that Language == Thought-space >= Implementation, so you want to maximize your language's expressiveness.

I could give you a hg but that would be Mercurial.

The |enom| issue I'm facing with time and space and map struct is, how many files can I link together before I cross the border of identity(?~ Before that I worry, can I keep _why a copy, by form of some command like "social vote share"?

(°hug.)

Re: Proposal: Go should have generics

#89

Post by eva1984 »

catfest wrote: post #23
ktamura wrote: post #12

Earlier quoted context omitted.

This. For better and for worse, Go was designed for "simplicity", and generics are anything but simple. I'd be very, very surprised if Go thinks about generics in earnest anytime soon. I don't say this in anyway to eulogize Go: In some ways, Go is pathetically unexpressive. That said, it currently fills that gap for writing middleware between C sacrificing too much developer productivity and Perl/Python/Ruby/PHP sacr…

I don't see why you'd choose Go instead of a JVM language like Java, you get the language simplicity (plus features like Generics) and the performance upside too.

Java itself is, IMHO, quite straightforward.

But setup a java toolchain, building, deploying, and a lot of other configuration if some heavy framework is involved, is non-trivial. Gradle is like a must for modern Java application, and mastering itself takes some efforts. Go, when coming to toolchain, it is pretty much battery-included, best-practice-builtin, sometimes even a little forced.

Language wise, Java recently has seem a more aggressive adoption of new and modern features, which is quite welcome for me personally, but it is still more LOC comparing to Go.

I think Go is the new Python for light to middle complexity web service, with fewer people. Java is more for mature stuff, for larger scale collaboration.

Re: Proposal: Go should have generics

#90

Post by Gibbon1 »

slantedview wrote: post #19

From the post: > As Russ pointed out, generics are a trade off between programmer time, compilation time, and execution time This misses the most important metric: quality. Lack of generics forces copying and pasting of code which inevitably lowers quality and increases defects. It's amazing to me that with the all the expense that crappy software causes, we're more focused on compilation and execution time. Last tim…

I often get crap when I mention most of the time execution speed is just not important.

However it is important vastly more important for google than me or you. Simply because google and a lot of other web companies are running on such tight margins.

Consider my company is paying maybe $200/mo for AWS. When we are doing half a million a month in business. Each cpu cycle for us represents a lot more revenue for us than google is making. The flip side is programmer time matters a lot more to you and me than to google.

Post reply on HN