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

A Proposal for Adding Generics to Go

blog.golang.org

Post reply on HN
Print view View original

181–190 of 273 posts

Re: A Proposal for Adding Generics to Go

#181

Post by uncledave »

travv0 wrote: post #172
uncledave wrote: post #166

Earlier quoted context omitted.

Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types! Dictionary >>, SortedSet >>> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the…

> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the hair starts to get thin on top. What does any of that have to do with generics?

Well the generic programming model tends to favour using light weight abstract data structures instead of well defined types. Those abstractions are by nature leaky so many internal concerns leak out of abstraction boundaries into the caller and give them one hell of a bad time.

Re: A Proposal for Adding Generics to Go

#182

Post by brundolf »

enneff wrote: post #174
brundolf wrote: post #168

Earlier quoted context omitted.

It seems to me like generics are extremely important for "library code", and not super important for "application code" (and in fact they can sometimes create more confusion than they're worth in the latter context). Go also seems like a language that thrives in smaller-scale, application-focused contexts (microservices being the obvious example). So in this light, and with the basic generic data structures supplied…

I generally agree but I note that any substantial project becomes largely composed of “library code” itself.

Right, and that's where the question gets muddy

Though again, Go as a whole seems ill-suited for scaling to larger projects because of lots of other limitations on its type system, reliance on conventions, implicit-defaults, etc. Which makes it well-suited to (and often used for) things like microservices, where each actual codebase is smallish. Codebases like these will tend towards having less "library-like" code anyway, which means they don't need generics as badly. There's synergy here in the language design.

So I guess what I'm saying is: leaving out generics seems like the more "Go-like" direction, will dovetail better with its overall philosophy, etc, and isn't without advantages. But it would also mean kneecapping the language when it comes to certain use-cases that it's never going to be great for anyway. It's the classic "opinionated" vs "everything for everybody" dichotomy

Re: A Proposal for Adding Generics to Go

#183

Post by philosopher1234 »

coldtea wrote: post #61
lkramer wrote: post #48

Earlier quoted context omitted.

Mostly concerned about having to read other people's code that uses it.

If others people code uses it, then those other people deemed it useful. So the argument for not having them now becames either: (a) they rather not have it available, because you personally don't find it useful (b) those using generic don't know what they're doing, and only people not using generic are smart, so it's better to not have them to prevent the clueless from being able to use them

This is a silly strawman. Developers often write hard to read code, and even if generics are useful to the writer, doesn't mean they are useful to the reader. Many developers do not consider the reader, or if they do, not very in-depth. You can also make the argument that generic code is uniformly harder to read than specific code.

Re: A Proposal for Adding Generics to Go

#184

Post by uncledave »

Smaug123 wrote: post #180
uncledave wrote: post #166

Earlier quoted context omitted.

Yeah that's ok until you have 20 million lines of generic ridden crapola pumped out by the lowest bidder. That's the hell I spent a good chunk of the last few years untangling on the C# front. Let's model this correctly! Oh no someone said fuck it, lets just use a bunch of generic data types! Dictionary >>, SortedSet >>> Several thousand out of bounds, missing keys, null reference exceptions, hash collisions and the…

`Dictionary >>, SortedSet >>>` This is not a problem with generics, but with C#'s lack of discriminated unions and/or tiny-types. Except what on earth are you doing with a dictionary whose keys are lists of dictionaries? I am quite sure someone has not modelled their domain correctly there. That's not something you can blame on the existence of generics - I shudder to imagine how much worse it could have been without…

I was exaggerating there I admit, mostly because I can't post some of the hell I've seen without breaking contracts. The worst example I've seen was a completely generic data type specified abstract syntax tree. I spent a couple of weeks rewriting that using concrete types and managed to find and fix tens of trivial bugs caused entirely by the design.

The point is really that it's hard to reason about such things and define if they are appropriate or not for a lot of people. It's a lot of rope to hang yourself with.

Re: A Proposal for Adding Generics to Go

#185

Post by coddle-hark »

brundolf wrote: post #168
tschellenbach wrote: post #11

We have a very large Go codebase here at Stream and not having generics is just not really as big of an issue as you think it is. There are plenty of work arounds if you get used to not having generics in the language. The fast compile times of Go are amazing. I was doing some Kotlin a few weeks ago and the difference is crazy. Go: Install deps, compile everything done in 5s. Doing the same in Kotlin, laptop freezes,…

It seems to me like generics are extremely important for "library code", and not super important for "application code" (and in fact they can sometimes create more confusion than they're worth in the latter context). Go also seems like a language that thrives in smaller-scale, application-focused contexts (microservices being the obvious example). So in this light, and with the basic generic data structures supplied…

It's a real pain in the ass not having generics any time you're working with algorithms and data structures. Linked lists? Graphs? Trees? Go is generally quite nice to work with but it implementing these basic structures again and again with different underlying data types makes me feel like I'm writing Java. Which is ironic because, you know, Java has generics.

Re: A Proposal for Adding Generics to Go

#186

Post by Smaug123 »

lkramer wrote: post #100
coldtea wrote: post #60

Earlier quoted context omitted.

> The only real cases I can see is creating new data structures Half of programming is creating new data structures. The other half is tranformations (e.g. map, filter, reduce, min, max, etc) which also benefit from being generic.

Sorry, when I said new data structures, I meant containers like maps and list, which I very rarely get to create day to day. I can see it for your transformations, but I have seldom seen cases where generics would really help (usually we're talking about comparing complex structure types that will need custom code anyway).

"Theorems for free"! By which I mean, when I'm coding something and it could be universally quantified on the type, then it's better to do so. That way, it's impossible to phrase certain errors. For example, a function `Set -> Set` must produce a subset of the input set; that's guaranteed by the types. I can't accidentally include the value 0 in my set, because 0 isn't of that generic type. The generic forces you to think in terms of the structure you're manipulating, rather than in terms of its contents.

Re: A Proposal for Adding Generics to Go

#187

Post by brundolf »

coddle-hark wrote: post #185
brundolf wrote: post #168

Earlier quoted context omitted.

It seems to me like generics are extremely important for "library code", and not super important for "application code" (and in fact they can sometimes create more confusion than they're worth in the latter context). Go also seems like a language that thrives in smaller-scale, application-focused contexts (microservices being the obvious example). So in this light, and with the basic generic data structures supplied…

It's a real pain in the ass not having generics any time you're working with algorithms and data structures. Linked lists? Graphs? Trees? Go is generally quite nice to work with but it implementing these basic structures again and again with different underlying data types makes me feel like I'm writing Java. Which is ironic because, you know, Java has generics.

I think the idea is that these fundamentals could/should be supplied by the standard library

Ironically, despite all their differences, Rust actually has a similar situation: it's really hard to write the fundamental data-structures in Rust, so they've put a focus on having really good standard-library implementations and people are generally content using those (in Rust's case it's because the borrow-checker makes pointer twiddling hard, but the outcome is similar)

Re: A Proposal for Adding Generics to Go

#188

Post by erik_seaberg »

ed25519FUUU wrote: post #118
__jem wrote: post #80

Earlier quoted context omitted.

In other words, go is the language you want your coworkers to write, not the language you want to write. :)

I agree totally with this sentiment. I love reading other people's Go code but not always writing it, which is basically the opposite of virtually every other programming language I've used.

I’m reminded of “languages designed for the masses”: https://news.ycombinator.com/item?id=899246

Re: A Proposal for Adding Generics to Go

#189

Post by throwaway894345 »

skrtskrt wrote: post #14
kitkat_new wrote: post #8

I hope at some point they manage to add it. I, however, discovered Rust in the meanwhile. It has generics. And it is not too complex either and has quite a few other bonuses.

I like Go, but I too in the meantime have dipped my toes into Rust and it's just so much better without being that much more complex. The learning curve is real but quite a bit overstated I think.

With Rust, sometimes I'm just breezing along wondering why people say Rust is hard. Then I try to deserialize some JSON into a type that borrows a reference...

Also, Rust struck me as quite a lot more challenging before non-lexical lifetimes and rust-analyzer, so it's possible that you're responding to outdated criticism.

Re: A Proposal for Adding Generics to Go

#190

Post by resonantjacket5 »

egeozcan wrote: post #21
skrtskrt wrote: post #14

Earlier quoted context omitted.

I like Go, but I too in the meantime have dipped my toes into Rust and it's just so much better without being that much more complex. The learning curve is real but quite a bit overstated I think.

There's this common belief that "rust is too hard", which used to be actually true, but the docs and the language itself came a long way since those times. I'd say: If you can code in C#/TS (or anything like) + go, then it only depends if you have a free weekend.

I mean the biggest change for most people with rust is really the borrow checker or aka the lack of a (automatic) garbage collector. I think it takes much longer to get used to it if one hasn't worked with say C or C++ before.
Post reply on HN