Hacker News Reader

Comment by mort96 | Hacker News Reader

I'm curious, what's a better solution for generics if you want some kind of container which doesn't need to care what type it contains? Is the better solution to just use the current C-style void* s everywhere and manually cast your objects to and from void* (or in Go's case, interface{}), leaving type safety to the programmer? Or is the argument that people shouldn't need to write containers, and all necessary container types should be a part of the standard library and impossible to re-implement using regular Go code? Or is code generation a good enough solution? Or are there other, nicer solutions to enable generic container types which can't be abused like Java-style generics can be?

I don't particularly care which direction Go goes in, and don't write a lot of it myself, but I'm very curious what the alternative is.

View on HN

I've been writing Go for five years and I've never had a pressing need to create my own generic container type. The built-in types -- arrays, slices, maps, and channels, or some composition of them -- have proved sufficient. When I do need a new type of container, it either ends up being specialized for a specific type, or it accepts generic types via interface. Like, I need a red-black tree for this one algorithm, but do I really need a generic red-black tree that can handle any type? The answer is almost always no.

I'm fine with Go having a handful of built-in generic containers+functions. In fact, I think most people asking for "generics" would have their true needs met by adding a few more built-ins to the language. I pursued that idea here: https://github.com/lukechampine/ply

I sympathize with the programmers who really do need generics and would like to program in Go, because I love the language. But the way I see it, 95%+ of programs don't truly need generics. I like the trade-off Go makes by omitting generics, and it makes me sad that the language could change in such a radical way to meet the needs of that <5%. A language doesn't need to be perfect (or even usable) for everyone! Throwing in feature after feature to satisfy everyone just creates a culture of compromise and destroys a language's character. I want a set of narrow tools that I can master. No one ever complained that a hammer makes a terrible paintbrush. So in a broader sense I think this whole discussion reflects a wider need for good languages. We need ten languages of Go's caliber! I know the "just use a different language" argument is kinda callous, but the alternative feels worse.

The irony is that the reason the built-in types like arrays, slices, maps, and channels are useful is because they're the only types allowed to be parameterized by types in the language. It'd be interesting to see how many people would defend this choice if they were forced to work with intArrs and stringToStringMaps, etc.

I don't have any opinions on adding generics to Go because I don't have a sense of how it interacts w/ other features of the language, but having to specialize all your types to specific uses means there are very common types of libraries that are significantly harder to find in Go than in other languages, or are much less useful, or work around the lack of generics w/ interface{} casts and are significantly less type safe. I suspect that people who deny the value of generics enjoy learning about the implementation of these things and writing them themselves rather than using libraries. Don't get me wrong, there's value in that, but it's at the expense of writing libraries with stable interfaces, boilerplate-free code, large systems that can easily be refactored, etc.

It also makes it harder to actually use a type system for the value it provides: the ability to encode facts about data irregardless of their provenance. Libraries may provide interfaces that work on a certain number of presumed useful primitive types, but your own types can encode far more constraints. Without the ability to use those types you will have to care about provenance again (has this value been validated for use by this function?) or constantly reuse a normalization process to construct those values, which may introduce conversion overhead and creates more error-prone situations. Not to mention that generics also provide constraints about what a piece of code _cannot_ do. The example made famous by haskell programmers is that an "fmap" function defined as such cannot tamper with the values being mapped over, since it has no knowledge of their concrete implementation:

fmap :: Functor f => (a -> b) -> f a -> f b

Genuinely, I don't understand why you would create a static type system in a new language that didn't allow for parametric polymorphism, it's one of the most fundamentally useful features in type-checking code.

> But the way I see it, 95%+ of programs don't truly need generics.

Yes, they do. Pretty much 100% of programmers in statically-typed language need to use generic types/functions.

The "95%+" thing is just an observation that one typically needs to define type-parametrized structures of function very seldom. This is true, but it's in no way a good point against adding generics, because those remaining ~5% of cases are crucial for peaceful programming the other ~95% of times. That's why Go has built-in generic types, but as it's adoption grows, it's becomming clear they won't do any more...

> In fact, I think most people asking for "generics" would have their true needs met by adding a few more built-ins to the language.

You argued against magic and now you'd like to add some more of it to the language...

Code generation by means of Go's standard template library has worked nicely for me. Best of all, gdb sees the concrete type, so value inspection stays easy.

Only snag, minor enough, is that emacs auto-indent becomes confused by the double braces, as in "{{.templateVar}}".

I've learned to be wary of the interface type. Although the run-time overhead is negligible anywhere outside tight loops, induced debugger overhead can become a misery.

Reply on news.ycombinator.com