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

171–180 of 439 posts

Re: Proposal: Go should have generics

#171

Post by mattlondon »

XorNot wrote: post #116
kqr wrote: post #102

Earlier quoted context omitted.

Completely oblivious about Go, but can you not provide a key function to the sorter that reaches into the struct and pulls out the field you want to sort on? (And presumably explodes in some spectactular fashion if it doesn't exist.) Or is that the "unsafe" reflection you're talking about?

For struct's at least, the answer would be to use an interface method which exposes the key field you want to use. This would be type-safe - you wouldn't be able to pass a non-conforming struct to the sorter. EDIT: I'd argue what we need in Go is something like a type-class for interfaces, so we can match on fieldsets the struct contains, and not just methods.

I think matching on fieldsets would be the ticket here.

I guess right now I could add a pointless no-op "marker method" to make each struct match a "CanBeSorted" interface, then have my sort function work in terms of things implementing CanBeSorted, but that does not guarantee the fields I want to use are there.

Sigh.

I am hoping that the "no backwards incompatible changes" thing Go has wont prevent fixing things like this sorting nonsense. Right now, whichever way I approach this sort of thing just feels icky.

Re: Proposal: Go should have generics

#172

Post by zzzcpan »

scotty79 wrote: post #157
louthy wrote: post #149

Earlier quoted context omitted.

Or just use a language that supports generics instead?

I don't know. You'd have to switch ecosystems completely. When you need Go ecosystem and generics, only thing to do is go transpiler route.

There is also a route of a fork. Adding generics doesn't look very hard to me.

Re: Proposal: Go should have generics

#173

Post by stcredzero »

teps wrote: post #101

What people think of generic package instead of fine grained generics? https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX... I think they would really fit the language well. The good part is: * Only the package and import statement change, the rest of your code stay the same and is not cluttered * They are easier to reason about as it is more coarse grained * They do not break the compatibility The the bad…

I like this idea. It would allay a lot of complaining.

Re: Proposal: Go should have generics

#174

Post by possibility »

bad_user wrote: post #168
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 think Go people have a very strange definition for simplicity, much like the population at large actually, but that's a shame really. Simple means composed of a single element, not compound, unentangled, being the opposite of "complex", which of course means consisting of many different and connected parts. Instead Go people prefer the term to mean the now more popular meaning, which is " easy to understand, famili…

Tying your two examples together, the GPL version of free/libre is way more complex than the simple BSD version.

Re: Proposal: Go should have generics

#175

Post by golergka »

enneff wrote: post #85
xiaq wrote: post #77

Earlier quoted context omitted.

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.

Maintenance.

Re: Proposal: Go should have generics

#176

Post by golergka »

Lack of generics was one of the reasons I abandoned Go halfway through a hobby project (the other reason was lack of normal exceptions).

But. Go's principle is simplicity and understanding the concepts you're working with. And generics as a concept is a little bit more complex than simple List explanation leads you believe. As C# developer (language with very good generics support), most of other C# developers I've met, unfortunately, can not easily and confidently explain covariance and contravariance concepts in an interview setting — which means that they don't understand generics concept completely. Mix it up with "null" virtual type, and you've got yourself a type system that you think you understand, but really don't, and will discover this misunderstanding in the worst possible moment.

So, while Go sucks for projects that I personally usually work on, its qualities make it a great language for other kinds of projects, and for these projects, generics may not be wort it with a trade off with simplicity.

Re: Proposal: Go should have generics

#179

Post by musha68k »

The one thing that makes Go special is that it's pure "Engineering-Zen".

While that doesn't make programming in Go the most fun exercise it makes it a profound one (after some getting used to).

Less distractions, less eGo (forgive the pun).

Disclaimer:

I'm still having a hard time embracing all of that myself - I don't even like Go.

I really miss all the functional cleverness I've come to get used to over the years - especially talking Erlang/OTP as the main (losing) "competitor" for most of my backend projects here (microservices, kubernetes yaddayadda).

Re: Proposal: Go should have generics

#180

Post by kaffeinecoma »

sievebrain wrote: post #151
louthy wrote: post #149

Earlier quoted context omitted.

Or just use a language that supports generics instead?

The first company to make a fork of Go that runs on the JVM and has compiler-specific extensions will make a ton of money, IMO.

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.
Post reply on HN