Hacker News Reader

Comment by mitchellh | Hacker News Reader

I agree you with you about generics, but downvoted you anyways, because "it gets ugly fast" is not true. I've certainly felt the pain of wanting generics for some data structures, but I've never felt the pain to where I've needed to make specialized structures for more than 2 or 3 types. And it had no real effect on the rest of my code. It was just one of those things where if I had generics, I could remove the 3x duplication of some code. It definitely doesn't ruin the language.

View on HN

I want map (the function). I want filter. And I don't want to keep rewriting them over and over when I work on projects.

They're not required -- indeed, I get by without them --, but the topic of the OP is elegance.

Precisely.

Other languages, Nimrod for instance (http://nimrod-lang.org/system.html#515) can manage this while still keeping a simple core, including lots of type-inference. Having generics doesn't automatically turn your language into Java.

The map operator in Nimrod has a definition that is clear and simple:

    proc map[T](data: var openarray[T]; op: proc (x: var T): S): seq[S]

I wrote this to scratch an itch of mine: There is nothing about go which prevents the use of generics. I wrote the following library to scratch an itch of mine:

https://github.com/mediocregopher/seq

It provides clojure-like data-structures and functions for interacting with them (like map and filter). It's completely immutable and generic, and supports lazy operations.

Yes, if you totally throw away the type information, then Go will let you write some generic code. Your library uses a _ton_ of `interface{}`, because it has to.

One of the main jobs of a programming language is to reduce the amount of duplication you have to write. It just seems to me like being okay with that is antithetical to progress in practical language development.

That's not what Go thinks its job is at all. Go thinks its job is to make it easier to write and maintain large scale software applications. Removing the amount of duplication that any one developer has to write is not one of the design criteria.

If you're not running into the issues that Go is trying to solve, you don't understand why its solutions are at least somewhat interesting, nor why its trade-offs are reasonable.

>Go thinks its job is to make it easier to write and maintain large scale software applications

It thinks wrong. Making people duplicate code makes it harder to write and maintain large scale software applications.

Please throw this Java mentality away. Code duplication isn't an issue, code maintenance is. While lack of duplication might help, it is in no way a necessity for a maintainable code base.

... until you find a bug duplicated x times in all your versions and you missed one of the x different unit tests to test them all ? IMHO when you are fighting your language to avoid code duplication, you either use it incorrectly or something is wrong about the language. To be honest, I only encounter rare cases where, dammit I would really love generics. And the Go team never said no to it, they just have more urgent stuff to do first.

[Disclaimer: Googler here using Go, yaddi yadda, this is just my opinion]

If code is duplicate of some other code maintenance increases 2x. If it's in ten places, it's 10x. If two different version diverge and they should really be the same (but for some reason one has data packed into an array and the other has multiple arguments, etc.) it becomes impossible to fix it without breaking something

>Please throw this Java mentality away. Code duplication isn't an issue, code maintenance is.

Actually what you describe is the Java mentality exactly! That's why Java is full of code duplication and is supposed to help with code maintenance.

Any language which prevents you from removing '3x duplication of some code' is ruined.

Reply on news.ycombinator.com