Hacker News Reader

Comment by weberc2 | Hacker News Reader

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.

View on HN

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.

> 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.

Reply on news.ycombinator.com