Hacker News Reader

Comment by tptacek | Hacker News Reader

It remains a selling point, and a concern for some Go developers. There's a lot of cognitive overhead in pervasively-parameterized codebases, and many developers would rather spend their cycles thinking about their algorithms or their problem domain rather than following extra layers of indirection.

I'm psyched to see generics arrive, but (I say this a lot) I write about as much Rust as I do Go these days, and there is definitely a cost to pervasive generics. I hope Go retains most of its original spirit, while at the same time making it easy for some people to write red-black trees or whatever.

View on HN

> there is definitely a cost to pervasive generics

I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse. I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up.

> I think as type systems stop being a limiting factor, it's important we learn to moderate our own tendency to abstract. Go's ethos so far has been to enforce moderation of complexity at a language level, so it will be interesting to see what happens when generics open part of that up.

I agree with this a lot. Relatedly, Go has this nice property that code tends to be pretty 'standard' regardless of who wrote it (facilitates reading and writing). I hope the additional expressiveness that comes with generics doesn't harm this 'standardization' property of the ecosystem.

> I've had a similar experience with TypeScript, whose type system is so breezy and flexible that it encourages levels of genericism I've not seen anywhere else, for better or worse

I wonder if this is a consequence of TypeScript's breezy generics or if it's because people are now adding types to the egregiously abstract things they were already doing in JS.

I would guess the driving factor is TypeScript's powerful inference capabilities. You can write generic functions all over the place, with multiple (sometimes interrelated!) type parameters, and you rarely have to pass explicit type arguments when calling anything. TypeScript will just figure it out. This removal of overhead when using complex types probably makes people less averse to creating them in the first place. Rust has a similar story.

> There's a lot of cognitive overhead in pervasively-parameterized codebases

The lack of generics leads to occasional excesses in code generation (-cough- k8s/client-go -cough-) which can be even worse. I suspect that observing this in practice lead the Go core team to be more receptive to generics proposals.

Go's simplicity is definitely a big selling point for me.

let's hope generics doesn't become a over(ab)used feature, that'd make the code harder to read and my experience harder to maintain, especially because when you need to fix something it takes a lot of time getting in context so you can actually write the code for the fix.

I mostly write Go these days and haven't found many use cases where generics are needed but there are definitely cases where they would make the code nicer.

Okay, but it's Rust that is going the Boost template metaprogramming route?

In practice I suspect this will lead to a Python 2/3-like fork in codebases, given the amount of electrons and emotions poured into the topic so far.

How do you figure? Python 3 isn't compatible with Python 2.

I think that's the point of the reply, that we'll get codebases that aren't mutually compatible due to a resistance of or lean towards using generics.

I'm not so certain that that's the case, but it is an interesting position nonetheless.

There is no such thing in Go since the language / runtime is very stable / backward compatible.

I think you may have missed the thrust of the earlier comment (which is that some developers may elect to never use libraries that use generics, whereas some developers may prefer libraries that use generics, and it could cause a schism in the community without being a necessarily language-level-breaking change), but it's also worth noting that Go absolutely has broken tooling through a language update in the past (https://github.com/golang/go/issues/24661) and just generally does not have a particularly great history or coherent philosophy of good versioning practices and as such we should not just assume stability or backwards compatibility where there may not be any.

What's a major Go project that had to be ported, or maintained in two separate versions or branches, in order to target two different versions of the Go language itself? I don't think the Python comparison is particularly apt, whatever our other concerns about Go stability might be.

In a social/cultural sense, rather than a purely technical sense. Old Busted C++ vs Modern C++ might have been a better example.

Pre-generic and post-generic codebases will likely play awkwardly together, with lots of boxing between generics and interface{}. Folks who prefer generics will start to wrap or recreate popular existing libraries in the generic style.

It'll be a constant drag on everything.

Of course I may be wrong and the community might embrace the proposal whole-heartedly. But I won't hold my breath. Dismissing generics has been a gopher shibboleth for years and years.

Reply on news.ycombinator.com