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

171–180 of 273 posts

Re: A Proposal for Adding Generics to Go

#171

Post by skrtskrt »

recursive wrote: post #143
mikepurvis wrote: post #105

Earlier quoted context omitted.

New concepts, yes, but I think anyone who has spent any significant time programming in C++ will immediately recognize the problems that they are solving and how the solution works. That significantly eases the learning curve in my opinion.

But we weren't talking about those who had spent significant time working in C++.

Indeed I am coming from Python (and some Go), and I'm coming to Rust because I want a language that makes me think about these things. But those who do not want to be bothered are likely to be turned off.

Re: A Proposal for Adding Generics to Go

#172

Post by travv0 »

uncledave wrote: post #166
stickfigure wrote: post #99

Earlier quoted context omitted.

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

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?

Re: A Proposal for Adding Generics to Go

#173

Post by gher-shyu3i »

rowanseymour wrote: post #63

I rarely find myself frustrated with the lack of generics in Go and am so glad to never deal with the kind of over-engineered generic madness that is so common in Java, except... When dealing with collections. It's maddening to have to keep duplicating basic functions like getting the keys from a map, or checking if a slice contains a given item.

> and am so glad to never deal with the kind of over-engineered generic madness that is so common in Java

Over engineered how?

Re: A Proposal for Adding Generics to Go

#174

Post by enneff »

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…

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

Re: A Proposal for Adding Generics to Go

#175

Post by strken »

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,…

When I worked at $big_company, we used a lot of code generation and reflection to work around the lack of Go generics in things like API interfaces to other services and test mocks. This was far from ideal, because it significantly increased compile times, and some things stopped being typesafe or had unfortunate type-related bugs.

Re: A Proposal for Adding Generics to Go

#176

Post by jjtheblunt »

masklinn wrote: post #77
jjtheblunt wrote: post #55

Earlier quoted context omitted.

isn't generic Sets easily implemented with map being already generic?

> isn't generic Sets easily implemented with map being already generic? Since Go has neither generic functions nor generic typedefs you can't implement a Set with a generic key type on top of map, you have to reimplement all the set operations for each key type you use.

I see what you mean there.

Re: A Proposal for Adding Generics to Go

#177

Post by enneff »

jacques_chester wrote: post #136
dilap wrote: post #67

Earlier quoted context omitted.

> Thanks the "first principles" design of go mod, that's becoming increasingly unavoidable. That's interesting, could you explain this more? Context: I used to use Go a lot, but mostly haven't since Go modules, and I'm curious to know the details of the problem and why it happens.

It doubles down on Go's assumption that git repository === a proper package/module system. It mixes up URLs and URNs. If your git repositories aren't tagged just so , then go mod throws its hands up and simply invents a whacky snapshot version. Because it can't itself properly determine "earlier version" from "later version" on that snapshot, you often wind up with multiple snapshots from the same repo, not infrequen…

> you often wind up with multiple snapshots from the same repo

Either I’m misunderstanding you or you’re mistaken. You can’t have multiple versions of the same module in a go build.

Re: A Proposal for Adding Generics to Go

#179

Post by enneff »

randomdata wrote: post #114
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,…

The biggest challenge is avoiding the tricks from languages that allow you to use the language to paper over questionable design choices. Go requires that you get the design right up front and provides few escape hatches to save you if you mess up. Which is a good thing, but makes the language (not just the syntax) difficult to learn compared to others.

IMO Go’s escape hatch for screw ups is its superb refactor-ability.

Re: A Proposal for Adding Generics to Go

#180

Post by Smaug123 »

uncledave wrote: post #166
stickfigure wrote: post #99

Earlier quoted context omitted.

I remember thinking something similar about my Java 1.4 codebase back in the early 2000s. It's fine, right? What could I be missing? The answer is: A lot.

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 generics!

Post reply on HN