>
As with any feature it should solve a set of problems, if the problem isn’t solved in the best way possible by the feature then it’s either not a good feature or of very limited value.This is disingenuous -- just to set an artificial barrier against generics.
Go doesn't solve any problem in the "best way possible":
- "Blessed" containers like Go's hash tables are not "the best way possible".
- The way it handles goroutines/channels has issues (mutability/pointer issues, not pre-emptive, etc). Again, far from "the best way possible" (that would be Erlang maybe).
- The GC was far from the "best way possible" or even "really good". Especially on the earlier versions (and crap on 32-bit).
- Losing type checks by having to use interface{} for generality, or resolving to BS textually generated code with custom string templating is not "the best way possible".
So why only Generics has to be "perfect or bust"?
And then there's this gem, about the (lack of) need for generic data structures:
>map/slice suffice for most of the cases encountered in programming.
...
Or this "con", about having generic to help with functional fold/zip/map:
>The fastest solution needs to take into account when and which order to apply those transformations, and how much data is generated at each step
So, in other cases the hit from interface{} is OK, but suddenly now those operations have to be "the fastest solution".
(Not to mention that the fastest solution, application order etc are orthogonal to Generics).
This is disingenuous -- just to set an artificial barrier against generics.
Go doesn't solve any problem in the "best way possible":
- "Blessed" containers like Go's hash tables are not "the best way possible".
- The way it handles goroutines/channels has issues (mutability/pointer issues, not pre-emptive, etc). Again, far from "the best way possible" (that would be Erlang maybe).
- The GC was far from the "best way possible" or even "really good". Especially on the earlier versions (and crap on 32-bit).
- Losing type checks by having to use interface{} for generality, or resolving to BS textually generated code with custom string templating is not "the best way possible".
So why only Generics has to be "perfect or bust"?
And then there's this gem, about the (lack of) need for generic data structures:
>map/slice suffice for most of the cases encountered in programming.
...
Or this "con", about having generic to help with functional fold/zip/map:
>The fastest solution needs to take into account when and which order to apply those transformations, and how much data is generated at each step
So, in other cases the hit from interface{} is OK, but suddenly now those operations have to be "the fastest solution".
(Not to mention that the fastest solution, application order etc are orthogonal to Generics).