3 ms·
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 n
by emodendroket 6y ago
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.
- throwaway894345 6y agoI 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).
- emodendroket 6y agoI thought dynamic arrays might be a more recognizable term to people who aren't already Gophers.
- throwaway894345 6y agoFor sure; I wasn't trying to correct you--I just used both terms for clarity.
- peq 6y agoApplications 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.
- emodendroket 6y agoThe 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.