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

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

101–110 of 288 posts

Re: Go: Support for Generic Methods

#101

Post by layer8 »

someone_19 wrote: post #84
layer8 wrote: post #24

Earlier quoted context omitted.

It’s still annoying ~20 years after Java did the same mistake of not including generics, which was already clear to many people with C++ experience back then.

...and Java didn't even have basic enums or sum types from the beginning. But it had null. They added enums, they added sealed classes. They're trying to get rid of null (apparently it's really hard). The problem is that in 2012, when go 1.0 was released, this should have been obvious to everyone. Here's a famous discussion from 2009, three years before the 1.0 release (tldr: facepalm) https://groups.google.com/g/gol…

I remember back in 1995 thinking that it was stupid for Java not to have generics, so instead you had to always cast Vector/Hashtable elements from Object, or implement your own type-specific container classes for every element type (and there wasn’t even a preprocessor to facilitate the latter).

Sum types I didn’t really miss, because you can implement a type-safe equivalent using the Visitor pattern, and retain an interface-implementation separation that native sum types typically don’t provide.

Re: Go: Support for Generic Methods

#102

Post by tines »

skywhopper wrote: post #78
tines wrote: post #64

Earlier quoted context omitted.

From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".

Is anyone actually mad about this, or do people just bring it up to stir the pot? Who cares what the FAQ says? They've worked out a way to add it easily in a backwards compatible way that can solve some problems. They had not identified this solution at the time they wrote the FAQ, and Go has been perfectly usable without this feature for 16 years.

I'm not mad, I'm a proponent of stronger type systems. I'm just correcting the record about

> They didn't say they never wanted to do generics, but that they did want to take their time and do them right.

Re: Go: Support for Generic Methods

#103

Post by stouset »

thayne wrote: post #96
stouset wrote: post #76

Earlier quoted context omitted.

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> I personally can’t wait to see what next development will never have been “against the Go philosophy” and definitely not something that gophers argued was perfect the way it was any time misguided malcontents and rabble-rousers wrongly tried to suggest the language wasn’t perfect the way it was. I really hope it is more ergonomic error handling. Or maybe sum types/discriminated unions.

Those are fine the way they are. I don’t want the language getting more complicated. Rob Pike has said they’ll never happen. Suggestions like this are extremely against the Go way of doing things. Actually the verbosity is a good thing. It’s explicit.

Re: Go: Support for Generic Methods

#104

Post by ncruces »

tines wrote: post #75
entrope wrote: post #73

Earlier quoted context omitted.

You keep posting that. Do you understand the difference between that and "we anticipate that Go will never add generic methods"? What they actually said shows epistemic humility and recognizes that they might change their mind.

Hi! I'm a human being that is trying to understand the world and make friends along the way. I see you are too! Pleased to meet you. You asked the question > Where did "they" say "we" didn't need generics? And I (re)posted a quote from them, which sounds to me like, at the time, they believed that "we" Go users didn't need generics. They may have changed their mind, which is totally fine! But I do think it sounds lik…

Do you understand the difference between generics and generic methods?

We already had generics when they wrote "we don't anticipate adding generic methods."

Re: Go: Support for Generic Methods

#106

Post by tines »

ncruces wrote: post #104
tines wrote: post #75

Earlier quoted context omitted.

Hi! I'm a human being that is trying to understand the world and make friends along the way. I see you are too! Pleased to meet you. You asked the question > Where did "they" say "we" didn't need generics? And I (re)posted a quote from them, which sounds to me like, at the time, they believed that "we" Go users didn't need generics. They may have changed their mind, which is totally fine! But I do think it sounds lik…

Do you understand the difference between generics and generic methods? We already had generics when they wrote "we don't anticipate adding generic methods."

The OP didn't mention generics or generic methods :) They referred to something that was added, after the Go team didn't anticipate adding it. Sounds like a fair point to me!

Re: Go: Support for Generic Methods

#107

Post by 9rx »

stouset wrote: post #95
9rx wrote: post #37

Earlier quoted context omitted.

Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. The trouble is that Rust is older than Go and it was already confusing people into thinking enums and sum types are the same thing, so by using slightly different syntax, iota, Go avoided the whole confusion of users thinking that enums would behave like sum types instead of actual enums. Is your attempt at making…

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. So is nil. Care to make the same argument?

Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap".

There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stretch as it was perfectly suited to use within Google, but it didn't fit the typical solo developer's environment. Lack of generics made writing certain types of code difficult. You could be convincing in suggesting that Go did end up being used less than it otherwise would have because of those choices.

iota? It's just a construct that generates numbers (an enum). How does that kneecap anything? If it really bothers you, you can manually number the values by hand instead. Why would anyone reject a language because it allows you to optionally choose to have the compiler assign numbers automatically instead of forcing you to do it manually? The answer is nobody. In fact, most popular languages have something equivalent to iota.

Re: Go: Support for Generic Methods

#108

Post by chlorion »

fhn wrote: post #62
a-french-anon wrote: post #4

Earlier quoted context omitted.

Maybe, but personally I've become quite tired of programming languages "organically grown" as opposed to properly designed the first time. After a good decade of C then C++, I found ANSI CL (despite being a massive compromise and unfinished) much more coherent and complete than both.

so make your own and let's see how you do

I am actually working on my own language, and getting something better than Go is actually not that difficult!

The hard part about making a language is creating the stdlib and tooling and support for the language, but actually creating a language itself that has more features and better features than go can be done by a single person in a few months or a year probably, depending on how much experience they have.

Generics specifically are a great example here. A single person can implement a language with go-level generics fairly easily.

Re: Go: Support for Generic Methods

#109

Post by Joker_vD »

thayne wrote: post #96
stouset wrote: post #76

Earlier quoted context omitted.

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> I personally can’t wait to see what next development will never have been “against the Go philosophy” and definitely not something that gophers argued was perfect the way it was any time misguided malcontents and rabble-rousers wrongly tried to suggest the language wasn’t perfect the way it was. I really hope it is more ergonomic error handling. Or maybe sum types/discriminated unions.

> I really hope it is more ergonomic error handling.

They've publicly said no more language changes specifically for better error handling are coming, it will at most be the library-level improvements.

Re: Go: Support for Generic Methods

#110

Post by stouset »

9rx wrote: post #107
stouset wrote: post #95

Earlier quoted context omitted.

> Why is iota a massive kneecap to the language? It is semantically identical to enum in C and Typescript. So is nil. Care to make the same argument?

Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap". There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stret…

Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless.

Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped themselves by forcing all of the users of Go to continue dealing with this well-known footgun.

Does it mean Go isn’t popular? Of course not. C was popular. PHP was popular. JavaScript is popular. Go is popular. This is always in spite of their faults. But Go could have been better.

Post reply on HN