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

Proposal: Go should have generics

github.com

Post reply on HN
Print view View original

371–380 of 439 posts

Re: Proposal: Go should have generics

#371

Post by aninhumer »

AnimalMuppet wrote: post #368
loup-vaillant wrote: post #204

Earlier quoted context omitted.

He who takes his examples of generics from C++ and Java has a huge blind spot. The FP crowd came up with simple and useable generics (Hindley-Milner type inference) in 1982 . It's like Go's creators haven't even read Pierce's Types and Programming languages . This is inexcusable. Even more so from Rob Pike and Ken Thomson —you'd expect better from such big shots.

It's like you assume that, since they didn't do it your way, they're either stupid, ignorant, or malicious - which I also find to be pretty inexcusable.

I'd like to give them the benefit of the doubt, but even within their stated goal of "simplicity", some of their design choices still seem ignorant of PL theory. The obvious one being including a null value, which is widely recognised to be a terrible idea with pretty much no redeeming qualities.

Another subtler example is the use of multiple return values for error handling, rather than some kind of sum type. It just suggests the designer doesn't have any experience working with ADTs. (Not that I'm suggesting Go should have used full blown ADTs, just that they change the way you think about data.)

Re: Proposal: Go should have generics

#372

Post by plq »

There was a time when the only language with decent platform support had to have turing-complete meta-programming support, inheritance, polymorphism, lambdas, preprocessor, custom allocators, placement new, std::erase_if, etc, etc. because we were basically stuck with it.

Those times are now way behind us. Today, there is a plethora of languages to choose from, each with their strengths and weaknesses, each most powerful in the niche it's designed for.

Go is not a language with generics. If you need generics, don't use Go.

Go should not have generics unless it's trying to dominate the world. And we all know that no language can achieve world domination nowadays, not anymore. So it should rather trying to be the best language possible in the niche it was designed for. That niche doesn't need generics. On the contrary, a vocal part of the community says generics would taint Go.

Go doesn't have generics. It's however got a proper FFI. Use it. Or don't.

Re: Proposal: Go should have generics

#373

Post by Arzh »

nanny wrote: post #319
Arzh wrote: post #278

Earlier quoted context omitted.

Code generation is not about a deficiency in the language, C++ has templating but I will often use code generation since you only need to run that once and templating bloats the compile time for ever.

>I will often use code generation since you only need to run that once and templating bloats the compile time for ever. Don't you need to compile the generated code?

Yes of course, but compiling the code is faster than generating the code and then compiling it. Templates are much slower than just compiling code straight.

Re: Proposal: Go should have generics

#374

Post by omginternets »

sievebrain wrote: post #324
omginternets wrote: post #282

Earlier quoted context omitted.

>typical Java IDE like IntelliJ So now I need to change my text editor?

No. If you want to use vim then you would just use Gradle or Maven as your build system, instead of Make.

Right, so then it is more complex than `go build`. QED.

To be clear, I'm not claiming that Go is "better"; I'm just pointing out that this is why one would chose Go over Java. Sometimes this particular benefit doesn't outweigh the costs relative to developing in Java, but language/toolchain simplicity remains -- nonetheless -- the reason why people prefer one over the other.

Re: Proposal: Go should have generics

#375

Post by AnimalMuppet »

aninhumer wrote: post #371
AnimalMuppet wrote: post #368

Earlier quoted context omitted.

It's like you assume that, since they didn't do it your way, they're either stupid, ignorant, or malicious - which I also find to be pretty inexcusable.

I'd like to give them the benefit of the doubt, but even within their stated goal of "simplicity", some of their design choices still seem ignorant of PL theory. The obvious one being including a null value, which is widely recognised to be a terrible idea with pretty much no redeeming qualities. Another subtler example is the use of multiple return values for error handling, rather than some kind of sum type. It jus…

Simplicity is, I think, a secondary goal. A big part of the motivation for creating Go was 45 minute C++ compile times. A major reason for the emphasis on simplicity is to keep the compiler fast, even on huge codebases.

So: How much would adding sum types slow down the compiler? I don't know. How fast does Go compile compared to Haskell? (Is that a fair comparison?)

Re: Proposal: Go should have generics

#376

Post by jdcarter »

stcredzero wrote: post #327
jdcarter wrote: post #314

Earlier quoted context omitted.

I've had a very similar experience from about 3 years of writing Go. The lack of generics hardly affected me. When it did, it was dead simple to write the type-specific code and move on. I've been working on a Java project recently, and by contrast, this code base abuses generics to an almost pathological level. I've also been burned by Java's runtime type erasure, and wow that leads to some nasty bugs. (That's not t…

Too often I've seen [X] lead to complexity and abuse which greatly outweigh their utility. Programmer hubris is a problem. There was a widely acknowledged problem in Smalltalk with the overuse of #doesNotUnderstand: and other esoterica to do "clever" stuff which then makes it difficult for new programmers to debug and understand the system. There is a reason why certain methodologies emphasize "the simplest thing tha…

Yes, thank you. When you use generics for a sortable collection class, that makes sense--it's a perfectly reasonable application of the technology. Problem is that "clever" programmers go hog-wild with generics and create APIs that resemble Greek tragedies where everybody dies in the end.

I think that the Go core team acknowledges this tendency, and that's why they resist adding features which tend towards complexity/abuse when those "clever" programmers get ahold of them. Sure, it means some minor pain when implementing the Sort API for your class. The unseen benefit is that you don't get the horrific abuse of generics that I'm seeing in my current Java job.

Re: Proposal: Go should have generics

#377

Post by tssuser »

Let me give a concrete example of how I've been personally impacted by the lack of generics. My project makes liberal use of pointers to represent "optional" fields, since they need to be distinguished from the zero-type. Alternatives would be to have a boolean associated with every field, but that clutters the API and still faces a lot of the problems with using pointrs, such as:

- Easy to forget to check that pointer != nil

- Overloaded semantics: it's unclear whether a pointer represents an optional type, or is being used to pass-by-refrence (i.e. unclear whether a value should be treated read-only)

- Need to deep copy every struct, which is easy to forget and inefficient (at least the reflect version)

There are solutions to each of these points, but they all add complexity (e.g. generating code), and most take a lot of extra effort. With generics I could have Optional, With a Get() function returning 2 values: the value type, and present (i.e. the way maps work). The caller is forced to handle both returns, making it much harder to forget to check it.

A lot of arguments for generics focus on higher-level functional programming abstractions, but this is a simple and extremely common use-case, and the lack of a solution is responsible for many real-world bugs.

Re: Proposal: Go should have generics

#378

Post by d4rkph1b3r »

stcredzero wrote: post #355
d4rkph1b3r wrote: post #334

Earlier quoted context omitted.

can you articulate the exact cost of adding generics? The benefits are profound, and the PL community has been doing research on it for the last forty some odd years. Some of the benefits are opportunities for * specialization * reduction in boilerplate * parametricity * free theorems * type classes Objectively, a collections library written with generics and no subtyping will be much better and cleaner than a subtyp…

Your comment is illustrative of a lack of awareness of context. You don't specify the context, but it seems like you're stuck in this academic/language theory mindset. From that standpoint, I rather like generics. It's clear to see how they can enable DRY if used judiciously. (Clear from even a freshman CS undergrad perspective.) However, as a professional who gets paid to wrangle C++, I find the "Tragedy of the Comm…

Ah, so you can't argue with me, so you're going to try the ol' appeal to authority ("i've worked on such big code bases that you'll never see").

You seem to assume I'm some naive recent grad. I've worked on more than a few 500k LOC applications. I'm a lead at a very large tech company (Fortune 50). The idea that '"clever"' programmers is a thing is incorrect.

There are good programmers and bad programmers. It doesn't matter if the lack of abstraction used by one type creates a monolithic mess of spaghetti code or if they use overly obscure attempts at abstraction. Bad code causes technical debt either way, and I've seen both done quite often.

Re: Proposal: Go should have generics

#379

Post by aninhumer »

AnimalMuppet wrote: post #375
aninhumer wrote: post #371

Earlier quoted context omitted.

I'd like to give them the benefit of the doubt, but even within their stated goal of "simplicity", some of their design choices still seem ignorant of PL theory. The obvious one being including a null value, which is widely recognised to be a terrible idea with pretty much no redeeming qualities. Another subtler example is the use of multiple return values for error handling, rather than some kind of sum type. It jus…

Simplicity is, I think, a secondary goal. A big part of the motivation for creating Go was 45 minute C++ compile times. A major reason for the emphasis on simplicity is to keep the compiler fast , even on huge codebases. So: How much would adding sum types slow down the compiler? I don't know. How fast does Go compile compared to Haskell? (Is that a fair comparison?)

I'm a little dubious of the speed advantage to be honest. Sure compile time is important, and C++ is pretty bad on this front, but you don't need to try that hard to do better.

And no, I don't think sum types would slow the compiler down much, especially if they were limited to a special case for error handling (which seems more in line with the rest of Go).

Re: Proposal: Go should have generics

#380

Post by d4rkph1b3r »

zimbatm wrote: post #364
d4rkph1b3r wrote: post #334

Earlier quoted context omitted.

can you articulate the exact cost of adding generics? The benefits are profound, and the PL community has been doing research on it for the last forty some odd years. Some of the benefits are opportunities for * specialization * reduction in boilerplate * parametricity * free theorems * type classes Objectively, a collections library written with generics and no subtyping will be much better and cleaner than a subtyp…

Generics introduce more complexity in the type system which in turn makes the compiler slower. Generics introduce more complexity for the reader of the code because it's another abstraction to understand. It's debatable but when your brain is thinking about generics or context-switching because it has to wait on the compiler to finish, it's less time making progress on the actual thing that needs to be done.

The whole point of abstractions is that you don't have to worry about as much. Generics take away complexity, that's the whole point.
Post reply on HN