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

201–210 of 273 posts

Re: A Proposal for Adding Generics to Go

#201

Post by praptak »

stickfigure wrote: post #99
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,…

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.

Go (without generics) is not Java 1.4.

Go's built-in collections are actually generic and Java's generic-less awkwardness was mostly about collections.

Re: A Proposal for Adding Generics to Go

#202

Post by enneff »

brundolf wrote: post #182
enneff wrote: post #174

Earlier quoted context omitted.

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

Funny you should say that, because go was specifically designed for large code bases. I work on a large go code base and it’s great.

https://talks.golang.org/2012/splash.article

Re: A Proposal for Adding Generics to Go

#203

Post by wtetzner »

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.

I don't think I've ever seen generics be the cause of over-engineered complexity in Java.

It's pretty much always giant, complex class hierarchies or a bunch of reflection (or both).

Re: A Proposal for Adding Generics to Go

#204

Post by a1369209993 »

uncledave wrote: post #184
Smaug123 wrote: post #180

Earlier quoted context omitted.

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

The sufficiently stupid-but-hard-working programmer can write crap code in any language. The actually-useful question is whether the language gives competent programmers enough rope to build whatever they're trying to build.

Re: A Proposal for Adding Generics to Go

#205

Post by esarbe »

jcelerier wrote: post #147
esarbe wrote: post #134

Earlier quoted context omitted.

No, not acually. Generics in Go are vastly different than templates in C++. They might be used for similar things, but whereas Go's generics actually build up on Go's structural typing, templates are ... something completely different again. I mean; C++ templates are Turing complete. They are in the same ballpark as Scala's type machinery. And I say that with adoration.

> I mean; C++ templates are Turing complete. that's not a very high milestone to achieve. Even java generics are turing complete ( https://arxiv.org/abs/1605.05274 )

Holy crap, indeed!

The older I get, the more icky I find subtyping. It just makes things messy...

Re: A Proposal for Adding Generics to Go

#206

Post by philosopher1234 »

brundolf wrote: post #198
philosopher1234 wrote: post #193

Earlier quoted context omitted.

Why do you say Go has trouble scaling to large code bases? Is that something you'd expect, or something borne out by the evidence? And if so, what is the evidence?

It's the subjective impression I've formed from, among other things, reading articles like this: https://fasterthanli.me/articles/aiming-for-correctness-with... Ctrl+F for "Let's start with Go" to jump to the relevant part

FWIW I would take fasterthanli.me with a grain of salt. The guy is a serial Go hater. His points stand on their own, but I don't think he appreciates Go's benefits. I think "A Philosophy of Software Design," Rob Pike's talks, or Russ Cox's blog posts are a good place to look if you want to understand what is valuable about Go and the reason to believe it would actually scale very well to large codebases.

Re: A Proposal for Adding Generics to Go

#207

Post by uncledave »

a1369209993 wrote: post #204
uncledave wrote: post #184

Earlier quoted context omitted.

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…

The sufficiently stupid-but-hard-working programmer can write crap code in any language. The actually-useful question is whether the language gives competent programmers enough rope to build whatever they're trying to build.

We shouldn’t build stuff for the 5%

Re: A Proposal for Adding Generics to Go

#208

Post by mumblemumble »

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 seems to me like generics are extremely important for "library code", and not super important for "application code"

I find that it really depends a lot on the language you're working in, and how well it does generics.

In Java, I don't use generics much beyond collections, streams, stuff like that. Whenever I try, I tend to trip over its relatively limited implementation of the concept.

In a language like F#, on the other hand, generics are the cornerstone of my business domain modeling. They provide a way to map everything out in a way that is much more concise, readable, type-safe, and maintainable than I find to be possible in many other languages.

I have yet to kick higher-kinded polymorphism's tires in a good context, but I can see where a good implementation of it would move things even further in that direction.

(edit: Disclaimer: This isn't meant to be a statement on Go or the advisability of this proposal. Go isn't really meant for the kinds of applications where I've seen real benefit from generics.)

Re: A Proposal for Adding Generics to Go

#209

Post by Jtsummers »

philosopher1234 wrote: post #194
Jtsummers wrote: post #106

Earlier quoted context omitted.

Ideally, if the language/standard library provides maps but not sets, and you wanted to use the idiomatic set = map of type -> bool approach, you'd create a wrapper so that intent is preserved but users don't have to know about the backing mechanism. Of course, it's obnoxious if everyone has to do this themselves and the language lacks generics so you have to write this once for each potential type.

Wrappers that don't wrap very much aren't worthwhile IMO. Its like getting an amazon box with a fedex box inside. Just give me the package itself.

Shallow wrappers that don't wrap much (now) but convey intent better are valuable if you buy into the idea of modularity and encapsulation in general. Some reasons (probably more out there):

1. The now-provided interface can more clearly express what the code is intending to do (better names for the operations you're providing than the underlying system has, remove_from_end to pop or dequeue)

2. Hide methods of interacting with the underlying data structures that you don't want people to use (use a C++ vector as a stack, but don't want random access)

3. You can replace the underlying mechanisms at will without impacting the users

If you just wrap a vector in your own vector class and otherwise provide the same operations (or a limited set of operations but for no good reason to restrict usage), sure, that's moronic. But if you wrap a vector class in a "BigNumber" class and provide operations like add, subtract, mod, etc. then value has been added. Same thing with the idea of wrapping a map in a set interface.

Re: A Proposal for Adding Generics to Go

#210

Post by bmurphy1976 »

AlphaSite wrote: post #129
anderspitman wrote: post #110

Earlier quoted context omitted.

I've used Java and Go. I find Go a far superior experience. Part of that is the standard library which seems to strike a perfect balance providing what you need but not too much. I also think a lot of it has to do with the culture of the languages. Kotlin is a pretty nice language, but using it for Android still makes me want to hit my computer with a hammer because the over-abstraction of the Java ecosystem is madde…

I was under the impression modern Java was becoming more functional than more OO (or at least de-emphasising inheritance).

It doesn't matter. Eventually you will need to use some library that's from the old days. You can't escape the abstraction. Not everything has been or can be updated to modern standards so just like C++ eventually every bit of the language ecosystem will come back to haunt you.

Go doesn't suffer from this yet because it's too new and the philosophy is different which keeps some of it at bay, but it's only a matter of time. Entropy always wins.

Post reply on HN