Hacker News Reader

Comment by emodendroket | Hacker News Reader

Well, the truth is a lot of applications don't actually really need generic data structures beyond those already provided (maps and dynamic arrays). If you do need that, yeah, you're in for nearly duplicate code. Over time I think you'll just start to approach problems differently and not really think about the limitation much, or that has been my experience.

View on HN

I agree. For the most part, I rarely use anything but slices ("dynamic arrays"). Once in a while I'll use a map, but only for large Ns, since maps don't have useful zero-values and they tend to incur more allocations (which are relatively expensive in Go) than slices (and generally lookups are slower for small N values).

I thought dynamic arrays might be a more recognizable term to people who aren't already Gophers.

For sure; I wasn't trying to correct you--I just used both terms for clarity.

Applications don't need generics, but libraries do.

The lack of generics is the reason for a lack of many useful libraries that I miss when writing applications in Go.

Things I missed lately: Sets, maps with arbitrary keys, lists, sorting, removing duplicates, priority queues, parser combinators, list transformation functions (map, filter), transactions.

Some of these exist for Go, but with awkward APIs.

The Go idiom for set is a map with bool values and given that it'll just return false for keys that aren't initialized I really don't see what you're missing compared to having a dedicated type. I'm not sure what your complaint is about maps, lists, or sorting. There are some specialized types you might occasionally want and I miss FP constructs too, but I don't think these are really serious impediments to productivity.

Reply on news.ycombinator.com