Why has the math package (and maybe others) not been rewritten using generics? It has been years now, since we had generics, and I still have to convert back and forth between float64 and float32/intXX when using the math.Abs() function, as an example.
It feels like math.Abs() should accept all numeric types, and all trigonomical functions, like math.Sin() etc, should accept at least float64 and float32.
Is there a reason for this, that I don’t understand?
Interesting, but why wasn’t it merged in 2022? What does it mean when Rob Pike says: Patch Set 1: Hold+1?
And it also fixed only the math.Abs() function…
Follow the links to the other discussions.
Ok, thanks, now I understand why it was rejected, I still think though that a new package should be created instead, for example math2, that supports generics. Backwards compatibility will be kept since math still exists…
Yeah, I don’t disagree that it’d be nice, I don’t know that creating that sort of precedent in stdlib is the best solution, but as per that discussion, I don’t know that there’s any good solution. I’m not sure what level of motivation there is to resolve it in stdlib considering how easy it is to have your own workaround/wrapper in your own projects.
And that is where I think we disagree a little bit. I don’t like to have my own workarounds for a “flawed” or “limited” standard library in my own projects. I am getting tired of fixing the standard library 
I love the idea of keeping the Go language small, but I don’t love keeping the standard library as minimized as the language…But I guess I’ll just have to accept it as it is…
Yep, in all languages, but especially low level ones, I always end up with my own traveling lib of helpful bits and bobs. Truth is I end up with that in all areas of life, I have a wide variety of jigs and other homemade tools for carpentry and working around the house too. So yeah, I guess I’m biased towards that sort of toolkit