I literally don't know what to say here. The whole point is to analyze the trade offs of generics rather than start out with a judgment that they are always worth it. In order to have generics supported in a language, you must pay for it some way or another. If you just box all of the values like (I think) you're suggesting and provide compiler support for it, then programs that use generics are going to pay a cost in runtime performance compared to programs that don't use them. In other implementations of generics, it's possible to remove that runtime cost (or almost remove), but usually at the cost of something else like implementation complexity or compiler speed. Programs that use generics with that implementation choice won't pay a runtime cost compared to programs that don't use them. This obviously has a significant impact on the decision procedure of whether to use generics or not at any given point in your program.
And yes, absolutely, saying generics has a cost is exactly like saying functions have a cost. The only difference between them is that there is clearly still a substantive amount of disagreement over whether full blown generics is always worth its weight in value (compared to the cost of not having them).
Currently, Go does not have anything resembling the term "generics." (Except for a few built in types and functions defined in the language specification.)
They aren't free...
I literally don't know what to say here. The whole point is to analyze the trade offs of generics rather than start out with a judgment that they are always worth it. In order to have generics supported in a language, you must pay for it some way or another. If you just box all of the values like (I think) you're suggesting and provide compiler support for it, then programs that use generics are going to pay a cost in runtime performance compared to programs that don't use them. In other implementations of generics, it's possible to remove that runtime cost (or almost remove), but usually at the cost of something else like implementation complexity or compiler speed. Programs that use generics with that implementation choice won't pay a runtime cost compared to programs that don't use them. This obviously has a significant impact on the decision procedure of whether to use generics or not at any given point in your program.
And yes, absolutely, saying generics has a cost is exactly like saying functions have a cost. The only difference between them is that there is clearly still a substantive amount of disagreement over whether full blown generics is always worth its weight in value (compared to the cost of not having them).
Currently, Go does not have anything resembling the term "generics." (Except for a few built in types and functions defined in the language specification.)