Hacker News Reader

Comment by gautamcgoel | Hacker News Reader

This will probably be downvoted, but I personally never felt a huge need for generics. C doesn't have them and is arguably the most successful language in history. Yes, they are convenient, but they also add a lot of complexity to the language and toolchain. I suspect that this proposal being accepted is largely due to the huge growth of the Go community - I bet the original team (in particular, I'm thinking of Rob Pike) are at best ambivalent about this proposal and were outvoted.

Personally, the proposal I was most excited about was to make ints be arbitrary precision by default. As someone who does a lot of math, this would have made Go much easier for me to use. Sadly, this proposal was scrapped a while back.

View on HN

> C doesn't have them and is arguably the most successful language in history.

I'm not sure "C didn't have it" is a good litmus test for determining the value of features... C is called a portable assembler for a reason.

> Yes, they are convenient, but they also add a lot of complexity to the language and toolchain.

Conversely, proponents of generics would argue that not having them creates complexity for software developers who have to come up with alternative design patterns where generics would be a better fit.

> Personally, the proposal I was most excited about was to make ints be arbitrary precision by default.

Why would you want that? C doesn't have it... ;)

Haha, touche. Your response is fair. My point was only that some people act like any successful language must have generics, which is demonstrably false IMO. I am not opposed to innovation and ergonomics (hence, my support for arbitrary precision ints), but we should carefully weigh the pros and cons of every new proposal, especially if it increases the complexity of the language and toolchain. In my opinion, the benefits of generics are outweighed by the cost of their complexity.

Well, we know now, contrary to what was said about generic-and-Go when Go came out: Go can apparently not do without generics.

What I always found hard to swallow is that Go's build in functions sometimes did have generics. Just you as a library/application writer were not allowed to create APIs with generics yourself.

Yep, seemed weird to me how (a form of) generics existed, but was exclusive to the stdlib/language.

If generics were unnecessary, why did the stdlib/language need them? Couldn't they just have lived with, e.g., make_map, make_slice, make_chan, etc?

Exactly. It was IMHO pretty authoritarian to say "you dont need generics" and then use it yourself in the standard lib.

But then Go is not a public place: it's private domain of Google.

I decided long time ago I dont want to learn a private tool without being paid.

And a separate copy of `append` for every possible type :)

First: I ninja-edited my comment after the fact with a thought that occurred to me after I posted, so apologies there.

Anyway, yeah, no argument there at all.

I'll be honest, as an outsider that's somewhat familiar with Pike's obsession with simplicity in Go, I'm actually a bit surprised this is getting in. It does seem like the kind of high-complexity feature that was deliberately excluded from the language as part of its overall design ethos.

But it really comes down to a weighing of pros and cons. Generics have the potential (though definitely not the guarantee!) to trade off developer complexity for compiler and toolchain complexity, and the preference on that choice is a personal one.

Well, then you also know he just didn't see any good implementations of generics, yet. Let's hope this gets good!

> I'm not sure "C didn't have it" is a good litmus test for determining the value of features

It can be a good test.

One reason why C is so ubiquitous is the simple binary interface. This makes it easy to reuse code since the libraries can be imported by every other language out there. C code is relatively simple and the compiled objects follow simple binary interfaces.

Adding features to languages almost always increases the complexity of these binary interfaces. Eventually they become so complicated that nothing will ever interoperate with software written in these languages. The increased language complexity reduces the reusability of software produced in that language.

C++ had this problem and Rust is following in its footsteps. Rust libraries are really only reused within the Rust ecosystem. Those that are meant to be universally reusable will no doubt offer a simple ABI that lacks all the benefits of the Rust language.

UNIX ABI.

C may not have generic types, but much of the standard library does use generics, just through the unsafe mechanism of `void*`. Likewise, go already includes some generic code (the array type), it's just treated specially.

The equivalent to a void pointer in Go is interface{}. But very little of the C standard library uses void pointers--basically only those interfaces dealing with untyped blocks of memory, such as malloc and free. IME, you see interface{} far more often in Go code than you see void pointers in C code. And C actually has bone fide generics capabilities with _Generic, it's just very simple and manual.

go's empty interfaces reminded me too much of the bad old days when everyone passed around Objects to java methods. I hated it.

void * is very useful as an opaque pointer type. For example, it's used all over the place in collection implementations and user-defined arguments (e.g., callbacks, pthread_create).

It might not be used much in the stdlib (which is relatively small!), but libraries and applications rely on void * heavily in my experience.

For me the desire to use generics shows up once I've invested some time in making fancy types. When I work in C that point is never reached since problems are solved "the C way".

Personally I'm a huge fan of generics but I can understand how the keepers of Go might be reluctant to go down the path of C++, Java and C#.

I think that C# has a successfull implementation because it isn't just about syntax sugar. The runtime knows it. Generics+structs allows many optimizations.

So true and portable across languages.

"I meant there are no plans for generics. That's not the same as saying we plan not to do generics. It just means we don't have a plan.

The FAQ is still accurate.

-rob"

"The time has come to change Go, given what we have learned over the past decade of using it in production. -rob"

the reason this proposal was accepted is because rob and others liked this plan and said over a decade of production taught them it is an important thing to have, in fact rob asked wadler and company to help get things right for go.. so i would say you'd bet wrong

> C doesn't have them and is arguably the most successful language in history.

And many C programs just emulate them using crazy macros, that are harder to write and are less typesafe than proper generics.

I was going to say -- the way you write a lot of "generic" code in C is with macros. Coming to Golang from C and having neither C-style macros nor proper generics was quite painful.

> I'm thinking of Rob Pike

I do not remember him being against generics. He is the one who contacted his former colleague Phil Wadler to help with the theoretical validation of the type parameters proposal. In his talk about the Go 2 draft specifications (back then the proposal was still based on contracts) he was positive that a good design can be found. (*) https://www.youtube.com/watch?v=RIvL2ONhFBI

C11 added _Generic as a way to write generic functions, for data structures people use the preprocessor to code-gen instantiations of generic code.

Rob Pike has nothing against generics and never expressed criticism of them. His concern was always fairly practical; among the numerous forms of generics that exist among different languages, and the significant variation and rapid evolution of them, how can such a feature be safely added to the language?

>I bet the original team (in particular, I'm thinking of Rob Pike)

Apparently he's nervous but can think of useful applications of generics: https://old.reddit.com/r/golang/comments/jditu9/what_do_gene...

Robert Griesemer was a coauthor on the Featherweight Go paper so I'm assuming he supports it. I would assume Ken Thompson doesn't care for generics but I think he's retired so he wouldn't vote on it anyway.

PHP was also hugely successful, success is not the criterion by which this kind of feature should be decided.

The bottom line is that generics allows the production of safer, more robust, more evolvable, more documented, more performant, code.

Along with static typing, generics are simply a feature that no language created recently should be without.

A successful language requires less effort to solve your problem. That's why we create them, and it's strange how languages keep becoming popular without nailing this.

and less readable, less auditable, less understandable, etc.

These are all subjective aspects which often confuse unfamiliarity with obfuscation.

I can read generic code in multiple languages even when I'm not fluent in these languages.

Once you get used to generic code, it actually becomes easier to read and understand than code where everything is type cast or Object typed all over the place.

Readability is far from subjective, if 50% of your devs can’t read parts of the codebase then it’s not readable.

Simple generic code is fine, but generics can be abused to over engineer things.

Agree with you on the generics, they make code harder to read and the biggest selling point of Golang is that it's easy to audit/read/understand.

IMO Golang needed sum types and match statements, but it didn't need generics.

Reply on news.ycombinator.com