> Generics are part of your language. They do not abstract over the language.

Most generics systems allow the code to be unfolded into generic free code; this is how templates are usually compiled in C++. So in a material sense the compiler treats templates as syntactic sugar added over C++ without templates (which is a valid language, which the compiler uses internally).

> C. Monomorphise at runtime.

A lot of generics (like my complex number example) can't be monomorphized at runtime since floats and doubles don't have dynamic dispatch in these languages. Not to mention the loss of type safety even if you implemented it this way. So that is not equivalent.

> And the code you "would have written anyway" is machine code.

That's not analyzing the cost of generics, that's analyzing the cost of the whole language, and then putting it on generics. If that's fair, why wouldn't we add the cost of designing and operating computers instead of doing it on paper? There's nothing special about machine code here.

> The abstraction leaks. You write one algorithm, and it has to be compiled into two different representations. That's the cost of the abstraction.

If (as in my example before) you need complex numbers with floating point numbers, and complex numbers with doubles, the compilation will likely be faster because the compiler doesn't need to take two parallel implementations through the whole parsing process, and can instead generate the necessary ASG itself. If you use on only one, then maybe there is a detectable differential cost.

Also, how is that even a leak? That's the abstraction working absolutely perfectly and giving you exactly what you intended.