Hacker News Reader

Comment by richard_todd | Hacker News Reader

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically.

The tupled (T, error) return types are a key area I think generics would help. The error-tuples themselves aren't the problem, but rather Go's inability to cleanly handle them. Threading error state around requires repetitive glue code (if err != nil). In some languages, you hide the glue code in monads. In some languages, you hide the glue code in macros. In some languages, generics reduce the glue to chained methods on helper objects. In Go, once in a while you can hand-write a lambda function to manage a closed-over error variable and clean things up a bit, but that's about all you get.

View on HN

I don't mind the repetitive glue code. It might be nice to clean it up a bit, but it's the least of my concerns with Go. When I miss generics, it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

> it's usually for some tree-like structure, but the cases where I need a high-performance tree structure and can't take the performance hit of `interface{}` are few and far between.

The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

Generics in java work via type erasure, so <T> is the same as interface{} by the time the code is running.

That's not relevant to type safety, though. Haskell also has type erasure.

Although I very much like C# where generics are not elided, I think most of the value comes from the productivity from static analysis, and therefore Java generics cature most of the value. Perf improvement opportunities are great though.

Absolutely not, they are not the same. Without generics, the compiler can't make any guarantees on the soundness of your code. Go will accept code that's inherently broken and that Java will simply refuse to compile. I like to catch such errors as soon as possible.

As for saying "they are the same once the code is running", well, duh, of course, but it's completely useless by then.

> The problem with interface{} is that it makes it pretty much worthless to have a type system at all.

I don't understand this argument. You need `interface{}` about 1% of the time; somehow it's better to have no type checking than only 99% type checking? Even in the 1% of cases, I've literally never seen a production bug (or even a failed test case) caused by a type error. I'm sure they happen, but I doubt they happen so frequently that adding in a generic type system would be a net gain.

exactly my experience

Except the 99% (though in my experience more like 80% of the cases where generics would be considered in other languages) of the time you are refraining yourseld from using interface{} and perhaps choosing another bad solution (lesser of the evils)

I don't think this is true in any meaningful sense. Perhaps you're talking about map() and friends, but these are so trivial that it's just as well to write out the for loop.

Performance is not the main problem with interface{}.

Indeed, but I think if they REALLY don't want to change the Go language, an officially blessed std library of "go generate"-able collections and algorithms would be an ok workaround for private use inside a package. It's extra work for the users, but you'd get widely-used, widely-tested, type-safe collections. The main problem would be interoperability when two packages independently generate an RBTree<int64,string> that Go thinks are different types.

Right, but it's a problem tagged-unions solve.

I miss generics, not because I would write new generic functions all the time, but because a few key generics provide infrastructure that increases the beauty of programs dramatically.

The problem is this: Have you ever worked in a mature codebase with generics, where they haven't somehow been overused? Please tell me where that is!

Having personally fallen into the trap of overusing C++ templates on a project, I understand the point. However, I did not go on to reject the idea that templates should be in the language.

Backing away from specific suggestions, I think it's healthy to recognize that Go has a boilerplate/DRY problem--not just with error handling!--, and it would be nice to address it in some way. If not with generics, then with something.

I've also worked on codebases that have overused the && operator. Should we remove that in favor of nested if?

Only if the cost-benefit works out, and there isn't a better solution.

And that's clearly the case with generics.

You're seriously saying that generically? All languages should simply have them? Not so sure you should dismiss the context like that.

> You're seriously saying that generically? All languages should simply have them? Not so sure you should dismiss the context like that.

Point me to a successful statically typed language born after 2005 that doesn't have some form of generics. Go has generics by the way, you just can define your own in user land, which is a stupid limitation.

Almost any powerful new feature in any language initially gets overused, but that isn't a reason to ban it.

Class hierarchies, for example, got heavily overused before people discovered that composition most of the time is the better option, exceptions got overused before people learnt to only use them in exceptional cases, and dependency injection and XML (one of the first environments with strong support for it) got overused in Java programs.

Generics are going the same way, if they haven't already (JavaScript modules will get there, too, but that seems at least a generation of programmers away)

Also, the only difference I see between generics (with a bit of 'compile-time reflection') and go generate is that the former may be too magical for some, while the latter requires programmers to do more work (writing special comments to use existing functionality, and writing AST manipulation code to write new ones) and that it generates files only because the compiler wants to see them.

Overused in what way? Do you have an example of what you mean by that?

I'm having a hard time understanding where using generics would cause problems.

C++ templates, sure, but those are much more powerful than just having parametric polymorphism.

C++ templates, sure

C++ templates! I keep on running into places where I'm debugging, then I find myself in a maze formed by template overuse, then debug around that instead.

just having parametric polymorphism

I think that could be workable in Go. I can imagine how debugging that would be straightforward.

As opposed to codebases that abuse interface {} and reflection ? I'd take the complexity of generics over this.

Yes, constantly. I've rarely seen generics overused.

Send me contact info.

Which is better, generics or macros?

Reply on news.ycombinator.com