Generics in java work via type erasure, so <T> is the same as interface{} by the time the code is running.
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.
Re:Seven years of Go
by magnushiie on Thursday November 10, 2016 @04:47PM
(#12924727)
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.
That's not relevant to type safety, though. Haskell also has type erasure.
> 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.
Re:Seven years of Go
by magnushiie on Thursday November 10, 2016 @04:44PM
(#12924693)
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.
The problem with interface{} is that it makes it pretty much worthless to have a type system at all.