2 ms·
Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing
by zimbatm 8y ago
Maybe that's the issue. From what I have seen, the lack of generics mainly becomes painful when working in the numerical space. If I work on mapping JSON, doing APIs and CLIs I don't really need generics. If I work on algorithms and data bags then it starts to be annoying re-implementing the same thing over and over again.
So in these discussion you have devops-type people mainly dealing with APIs that are perfectly content. And the ones that work with algorithms are talking past them because they don't experience the same pain.
Instead of changing the language to enable generics everywhere, maybe there is a lighter version that exists that only applies to numerical problems. Is it possible that a boxed "Number" type would solve most of the problems?
- phamilton 8y ago> mapping JSON I find that an ideal set of tools allow us to describe our task and write our code using the same idioms. The fact that "mapping JSON" doesn't actually involve calling "map" on JSON data is a great example of why not having generics in golang is frustrating for me.
- zimbatm 8y agoI forgot the 3rd category, those who see the world exclusively through the functional programmer lens :-D Mapping functionally it worth it if the transformation between A and B is regular enough. But things are dirty. Some irregularities appear and now the perfect higher-order function doesn't work nicely anymore. With the imperative approach it just means adding 1 -3 more lines.
- civility 8y agoI think you're exactly right: People who live and breathe JSON and strings don't (and probably shouldn't) care about use cases where the choice between float or double matters... I also see this with graphics people who live and breathe small (2x2, 3x3, and 4x4) matrices don't care about "type level integers" (as Rust calls them) to make 6x9 matrices efficiently live on the stack or in an array. > Is it possible that a boxed "Number" type would solve most of the problems? If you mean it the way I think you do, not for me. I can easily afford to fit a billion 4 byte floats in memory, but I can't afford a billion 8 byte box pointers to a 4 byte box with an n-byte tag, and the cache locality could be horrible. However, if Go had an elegant macro system (Rust's doesn't seem too bad), I could get by though.
- steveklabnik 8y agoGraphics people are one of the groups most often requesting type level integers. I’m sure many are fine without them, but many want them too.