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

241–250 of 439 posts

Re: Proposal: Go should have generics

#241

Post by NateDad »

junke wrote: post #211
enneff wrote: post #188

Earlier quoted context omitted.

This thread is about sort interface implementations. Their general form will never change, and the only specifics unique to any given copy are those specific to their type. It is obvious to any Go programmer what can and cannot be changed in this situation.

The thread was more about mattlondon's problem with sorting according to the same key in different structs. I used of modified version of this example[0] to illustrate what I think is his problem[1]: you can sort circles and planet by radius, and probably many other things in the original case, but you are required to copy-paste the definitions. I can understand that instantiating templates by hand is not so bad. But…

It's 3 lines of code the most newbie of newbies could understand... if this is the biggest problem I have in my day to day programming, I'll be happy.

Is it mildly annoying to type out those three lines? Sure. You know what's a lot more annoying? Basically everything else in programming.

Re: Proposal: Go should have generics

#242

Post by masklinn »

Intermernet wrote: post #239
masklinn wrote: post #136

Earlier quoted context omitted.

> Go doesn't do inheritance either. It has type embedding, but it's not the same. It does have interfaces though.

This is generally brought up as the reason that Go doesn't need generics. I tend to agree with this. I've yet to come across a use-case where the current system is too difficult to deal with, but there are other people who have hit this limitation. Maybe this can be solved by simply modifying the parsing of the keyword "type" (Or adding a reserved type "T") and telling developers that the functionality of "go generat…

> This is generally brought up as the reason that Go doesn't need generics.

Which I find nonsensical, but my point was that Go's interfaces are a form of subtyping, which as eru and tel note tend to have challenging interactions with generics.

Re: Proposal: Go should have generics

#243

Post by insulanian »

My code is full of map, filter, reduce/fold and similar generic reusable functions.

How do people deal with such things in Go? Do they really make copies of such functions for every type they're working with? (And by type I don't mean just int/string, but all model entities/classes.)

Re: Proposal: Go should have generics

#244

Post by _uhtu »

pjmlp wrote: post #208
thegenius2000 wrote: post #165

Earlier quoted context omitted.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

Go is thriving because it is Google sponsored. If it came from "Joe the dev" no one at HN would give it a second look.

Dart is also Google sponsored and no one uses it despite the fact that it's actually a pretty great general purpose language. People use go because it's productive and had a PHENOMENAL standard library for networking.

Re: Proposal: Go should have generics

#245

Post by thegenius2000 »

alkonaut wrote: post #202
Loic wrote: post #94

Earlier quoted context omitted.

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…

If code generation is used to make up for something missing in a language (be it generics, metaprogramming etc.) then that's a pretty clear sign something is wrong. It's definitely acceptable to use a workaround for a missing feature once or twice in a language, because no language is perfect, and no language benefits from being burdened with all features imaginable. But if a workaround becomes part of the day-to-day…

Well put. Though I would add that though generics are convenient, they are not as needed nearly often enough to be a crucial missing feature in a language. Yes, it's uncanny to copy here and there, and certainly, the Go team should try and resolve this. But from where I'm standing this (i.e. generics) is one of the very few fair criticisms of Go which can be leveled from the Java, C++ or C# communities.

Re: Proposal: Go should have generics

#246

Post by NateDad »

fauigerzigerk wrote: post #210
sievebrain wrote: post #184

Earlier quoted context omitted.

In a properly tuned system with sufficient CPU capacity there should never be any full GC pauses with G1. To get 10msec pause times with such huge heaps requires burning a LOT of CPU time with the standard JDK collectors because they can trade off pause latency vs CPU time. This presentation shows tuning with 100msec as the target: http://www.slideshare.net/HBaseCon/dev-session-7-49202969 Key points from the slides:…

>In a properly tuned system with sufficient CPU capacity there should never be any full GC pauses with G1. So you use a language without value types that makes you pay for two or three times more memory than comparable languages, and then you spend your time re-tuning the GC every time your allocation or usage patterns change. Then you hope to never trigger a full GC that could stall the VM for many seconds (or in ex…

100GB heap size in Go? How about 15ms pauses with zero tuning?

https://pbs.twimg.com/media/CWoAGeUW4AAy0-9.png:large

Re: Proposal: Go should have generics

#247

Post by justinlardinois »

aninhumer wrote: post #187
thegenius2000 wrote: post #165

Earlier quoted context omitted.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

The lesson Go seems to have learned is that, since C++ and Java burned their fingers, clearly fire is too dangerous for humans. The thing that makes it painfully obvious to me that Rob Pike hasn't bothered to learn anything from the PL community is that Go has nil. That just shouldn't happen in a modern language.

What's wrong with nil? Just legitimately curious, and I've never used Go at all.

Re: Proposal: Go should have generics

#248

Post by thegenius2000 »

louthy wrote: post #221
thegenius2000 wrote: post #165

Earlier quoted context omitted.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

That's just rhetoric. What does it mean? What lessons have been learned? What is it about generics that makes them the 'edge of the cliff'? Personally I couldn't live without generics, and would never choose a language that doesn't have them; otherwise you end up doing cartwheels with untyped references and reflection to try and write reusable code (as you see above). The idea that generics adds complexity is nonsens…

I clearly stated that Go is lacking on the generics front. The cliff is forced, rigid OOP and complicated tool-chains.

> Personally I couldn't live without generics, and would never choose a language that doesn't have them

I'm kind of confused here. Yes, Go needs generics, but are generics even that key a feature? I mean how often do you have to define a generic type, and how much copying does it really take? Is it a hassle? Of course. But at the end of the matter, Go much, much better when it comes to combining expressibility, efficiency, and simplicity then many of the other options available today.

Re: Proposal: Go should have generics

#249

Post by chmike »

Consider using the D language instead if generics is a problem. Go is what it is and shouldn't change. It has it's advantages that make it optimal for particular contexts. Otherwise you'll turn it into another c++. There is a strong benefit in keeping Go simple as it is.

Re: Proposal: Go should have generics

#250

Post by NateDad »

sievebrain wrote: post #186
kaffeinecoma wrote: post #180

Earlier quoted context omitted.

I doubt it. I did Java for over a decade, but jumped at the opportunity to use Go with its statically compiled binaries. The JVM is great, but being tied to it is kind of a hassle. Being able to hand a small binary to someone and say "here, run this" with no worry about dependencies- it's a beautiful thing.

The downsides are enormous. You can use the 'javapackager' tool in Java 8 to make a tarball that contains a JRE. It's not small, but that's a result of the age of the platform; it just has a lot of features (in Java 9 there is a tool that can make a bundled but stripped and optimised package). Go binaries are getting larger and the compiler is getting slower over time, as they add features. They don't have any magica…

Actually, the compiler is getting faster in 1.7, and binaries are getting smaller: http://dave.cheney.net/2016/04/02/go-1-7-toolchain-improveme...
Post reply on HN