I guess it need not be the case that generics will slow down compilation that much.

Problem with C++ template generics is that they are reinstantiated per type __per compilation unit__.

I think they can

* Use dynamic dispatch liberally - such that one instantiation per object size in order to avoid boxing. That said, I don't know how the experimental generics work. And this will obviously prevent some optimizations, notably escape analysis.

* defer compilation of generic code to the end i.e "just before linking" phase instead of eliminating duplicates at link time.

* Some kind of caching mechanism for generic code such that you `sed` the machine code / plan9 intermediate to replace it with type specialization wherever required - should work if you are willing to sacrifice some optimizations, As majority of time is spent in code generation. On the flip side, Go team can come up with different optimization strategy for that part of code because Go doesn't do many optimizations in current form.

I am no expert on compilers / optimization. But generics will obviously reduce the total code one needs to compile. And combined with some techniques I guess they can control compile times from regressing.