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?
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.
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.
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.
It also doesn't really work in Java either because you have to use the Object types.
Even in rust this looks pretty complicated: https://travisf.net/rust-generic-numbers
Maybe it's easy in c++?
I've seem a similar comment made on almost every discussion of this issue... are folks just not aware of the limitations with generic implementations?
Btw, it's "ironic" that you think pointing at two broken implementations says anything about where it works. "Are folks just not aware" it's ridiculous to be snarky when arguing from a position of ignorance?
But most other data structures? Nope. Too much of the algorithm depends on the primitive type.
And that makes generics a nice boon for computer scientists and certain library authors, but of middling benefit for day-to-day coding. If the container works, you can copy-paste-modify your way to the types you want, or automate the same in a macro or code generator. It's not beautiful but it doesn't have to be.
Generators are a legitimate solution and I wish they'd get more love.
It's so sad to see people pushing to radically alter a language that they will probably never use because it will never be suitable for their needs.
My biggest complaint about Go is the lack of generics; I bet they're just trying to get more adoption. That being said, adding generics won't eliminate all the other things I dislike about the language.
What's "so sad" is you think this Reddit style "Don't use it" imperative is an acceptable way to talk to people. You're rightfully afraid of complexity creeping into an otherwise clean language, but it would suck less if you said it better.
I won't argue with you my use of the imperative mood as I'm not a native speaker. I'll take note of it.