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

Generics aren't ready for Go

drewdevault.com

Post reply on HN
Print view View original

171–180 of 238 posts

Re: Generics aren't ready for Go

#171

Post by overcyn »

bunderbunder wrote: post #156
overcyn wrote: post #144

Earlier quoted context omitted.

No the two conflicting statements are. 1. Go doesn't have generics because the authors didn't have strong grasp of type theory. 2. Go doesn't have generics, not from a lack of knowledge, but because the authors' real world software engineering experience had shown to them it wasn't important.

Yeah, the second statement is also valid, though definitely not what I got from the parent's comment. Though, in that case, I think the argument is more like: 1. That shape is equilateral 2. That shape is equiangular It turns out it's a square. Rob Pike's public comments on the subject do seem to betray a weak grasp of actual type theory. Or at least one that is about as strong as it could ever get if your knowledge…

I am not Rob Pike and therefore cannot provide proof of his grasp of type theory. But I also don't understand the desire to question and debate the knowledge of someone I've never met and has no influence on my life.

I have used Go extensively and would disagree with the idea that the lack of generics in go was ill-informed (and therefore a mistake). I find that Go's limited number of features leads to simpler libraries that are much easier to comprehend and use effectively. And in situations where I previously would have reached for generics I am forced to find a different approach and the end result is often better. Yes it does have its drawbacks and is not a perfect solution, but as far as engineering decisions go, I feel it was a successful one.

Re: Generics aren't ready for Go

#172

Post by weberc2 »

jstimpfle wrote: post #115
weberc2 wrote: post #68

Earlier quoted context omitted.

What a bizarre criticism... If anything Go is a ruthlessly utilitarian language; utility above mathematical elegance. I say this as someone who values mathematical elegance. If I want mathematical elegance, I reach for a functional language; if I want to get something done, I reach (sometimes begrudgingly) for Go (and occassionally Python or JavaScript/TypeScript).

I even think that this utility (to me, it is synonymous with the simplicity from which it comes) has actual mathematical elegance. Whereas functional languages I find not particularly elegant once they hit the real world, must run on real machines etc. It gets ugly, complicated, or slow, really quick.

I agree, but it’s a different kind of elegance that is likely to be foreign to many folks in this thread, and I didn’t want to broach the distinction in this thread.

Re: Generics aren't ready for Go

#173

Post by Gibbon1 »

spion wrote: post #141
apta wrote: post #127

Earlier quoted context omitted.

> Go biggest advantage isn't the language, its the decent documentation and standard library design Which, ironically, Java is just superior in every way when it comes to documentation of the standard library. Large open source Java projects are well designed and very well documented, unlike golang projects.

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying. The Go documentation as well as standard interfaces are tastefully and minimally done (for an impera…

I'm under the impression that Java implements generics via type erasure.

Re: Generics aren't ready for Go

#174

Post by spion »

Gibbon1 wrote: post #173
spion wrote: post #141

Earlier quoted context omitted.

Java is not really superior in standard library design. There is too much architecture astronautics going on. Standard interfaces are too complicated. Nominal interfaces kinda suck. Java also lacks green threads. There is baggage in the design of many libraries related to previous lack of lambdas that is now annoying. The Go documentation as well as standard interfaces are tastefully and minimally done (for an impera…

I'm under the impression that Java implements generics via type erasure.

Thats not an entirely bad way to do it.

Re: Generics aren't ready for Go

#175

Post by latronic_notron »

jstimpfle wrote: post #154
latronic_notron wrote: post #153

Earlier quoted context omitted.

> Yes, but by far more important are bounds checks. Sure, but I'm failing to see why having other checks isn't important. I mean, generics aren't hard to use... They're way easier to grasp than Channels (a great feature), and easier to use daily than go generate. I dunno.

Many things are important, and most things require making tradeoffs. When a thing that is only a little bit important prevents something else that is more important (albeit more subtle and requiring experience to see), it's probably better not to choose the first thing. Generics are abstract . They lead to bad error messages. They make the language more complex. They require syntactical support as well as special mag…

I'm familiar with that article, and it got me excited for a while, but it's about compiler implementation, and it doesn't really have much to do with the current discussion, other than rationalizing the opposition for the feature.

About your other points: nope, generics wouldn't remove simplicity in the language itself. They would mostly legitimize with type-safety certain idioms that are already present in current Golang code. And the terrible error messages of C++ templates are not really a good example. There are much better languages now when it comes to generics.

I suggest that maybe you try looking into other legitimate uses of generics? The Fibonacci-Tree example you gave earlier is unrealistic, and the other example being thrown around here, STL, is too complex... There are lots of legitimate reasons for someone wanting generics in a language, and nobody is advocating for them out of bad faith, or wishing to kill a nice language with feature bloat :(

Re: Generics aren't ready for Go

#176

Post by spion »

latronic_notron wrote: post #168
throwaway415415 wrote: post #165

Earlier quoted context omitted.

Unfortunately I am not parroting. If you are used to read code, and you read c++, you will see that templates are abused. No generics force devs to make their code clearer and thus more secure. It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.

They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.

I would suggest a Go programmer give ReasonML an honest try (as an example language where "generics" are done right), but the getting started / documentation situation is still not at Golang level so thats a bit annoying.

Maybe F# would be a better choice. .NET Core and its tooling are pretty well done. C# and NET Core would be another nice alternative.

Re: Generics aren't ready for Go

#177

Post by Gibbon1 »

latronic_notron wrote: post #168
throwaway415415 wrote: post #165

Earlier quoted context omitted.

Unfortunately I am not parroting. If you are used to read code, and you read c++, you will see that templates are abused. No generics force devs to make their code clearer and thus more secure. It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.

They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.

I think generics in C# are really well executed and solve a lot of problems in C#'s problem domain.

I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java. C++ abuses templates and has dozens of ways to do anything that also don't interact with each other well. Java abuses inheritance, abstractions, and OOP.

go uses generics under the hood, probably the designers fear that generic's will also get abused if released into the wild. On the other hand I've never heard anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.

Re: Generics aren't ready for Go

#178

Post by weberc2 »

latronic_notron wrote: post #170
weberc2 wrote: post #158

Earlier quoted context omitted.

I'm talking about code written in Go, not the implementation of any particular feature. Generics would simplify those cases, but they also remove the rails that keeps Go code pretty consistent relative to Java or C#. For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experim…

> they also remove the rails that keeps Go code pretty consistent But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all. > For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative Why would generics break that? Funcional programming and type-sa…

> It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

And it sounds to me like you're working rather hard to misunderstand me/my-opinion and paint me an idealogue. :)

Even if I were making a positive assertion like "generics costs more than it gains", that would be a pragmatic viewpoint even if it's incorrect. But I'm not even making that assertion, I'm merely unsure and would like to be persuaded otherwise (and I find people with experience on both sides of the fence to be more credible than those without that experience).

> Why would generics break that?

Because "generics" as a feature suffices to support multi-paradigm programming. It explodes the solution space, creating many solutions for problems that Go's type system is perfectly capable of dealing with (~97% of the problem space in practice according to my experience) while permitting new solutions that Go's type system must currently punt on (~3%). We should be able to roughly agree on this even if we disagree about the degree to which multiple solutions is a problem relative to the advantage of the additional type safety.

Re: Generics aren't ready for Go

#179

Post by latronic_notron »

jstimpfle wrote: post #169
latronic_notron wrote: post #164

Earlier quoted context omitted.

Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.

I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case. func (p *parser) tryIdentOrType() ast.Expr { .... case token.MAP: return p.parseMapType() There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) do…

Yes, I'm aware that they're a special case. What I mean is that this is exactly what is traditionally called "generics" or "parametric polymorphism" in PL literature. Go's Map/Array/Slice called "predefined generic types" in some literature.

Re: Generics aren't ready for Go

#180

Post by latronic_notron »

Gibbon1 wrote: post #177
latronic_notron wrote: post #168

Earlier quoted context omitted.

They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.

I think generics in C# are really well executed and solve a lot of problems in C#'s problem domain. I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java. C++ abuses templates and has dozens of ways to do anything that also don't interact with each other well. Java abuses inheritance, abstractions, and OOP. go uses generics under the hood, pro…

> I do think you're on the right track that go's designers are pushing back hard on what they see as feature abuse in C++ and Java

Now that you mention it, I can't really blame them!

> On the other hand I've never heard anyone bitch about well designed generics in other languages. Which is a tell since people will bitch about anything and everything.

That's my opinion as well. Generics are quite pleasant, simple and a great tool to have when they're well designed.

Post reply on HN