6 ms·
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 o
by richard_todd 10y ago
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.
- weberc2 10y agoI 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.
- AsyncAwait 10y ago> 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.
- mappu 10y agoGenerics in java work via type erasure, so <T> is the same as interface{} by the time the code is running.
- jhomedall 10y agoThat's not relevant to type safety, though. Haskell also has type erasure.
- magnushiie 10y agoAlthough 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.
- hota_mazi 10y agoAbsolutely 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.
- weberc2 10y ago> 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.
- mseepgood 10y agoexactly my experience
- magnushiie 10y agoExcept 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)
- weberc2 10y agoI 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.
- pcwalton 10y agoPerformance is not the main problem with interface{}.
- richard_todd 10y agoIndeed, 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.
- weberc2 10y agoRight, but it's a problem tagged-unions solve.
- wsmith 10y agoWhich is better, generics or macros?
- stcredzero 10y agoI 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!
- richard_todd 10y agoHaving 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.
- pcwalton 10y agoI've also worked on codebases that have overused the && operator. Should we remove that in favor of nested if?
- stcredzero 10y agoOnly if the cost-benefit works out, and there isn't a better solution.
- pcwalton 10y agoAnd that's clearly the case with generics.
- stcredzero 10y agoYou're seriously saying that generically? All languages should simply have them? Not so sure you should dismiss the context like that.
- 10y ago