Consider how generics can be implemented in a compiled language:

a) specialize them at compile time - this means any library with generics in its API has to be distributed as source, and compiled *with or after* the code that uses it

b) erase them at compile time - they're just static checks, the type parameters can't affect behaviour, and everything becomes void* - no u64, vectors, or pass-by-value structs

c) specialize them at link time - now you need a new ABI and object format...

1/

And I think this affects other modern language features as well. Not sure which and whether they reduce to generics, but notice how most of the new compiled-to-native programming languages - like Rust, Zig, Go, Hare, etc - distribute libraries in source form, and compile them all together.

2/

Of the three options, I think (c) is the most attractive - it would make us no longer stuck with C-like APIs for anything dynamically linked.

But I'm not even sure if it's possible without using some intermediate language (like LLVM or some bytecode) as the object format, and delaying the generation of actual machine code until link/load time.

But maybe using LLVM-like IR for distributable objects wouldn't be a bad idea? How bad would it be to codegen at load-time?

3/3

@wolf480pl Interesting insights! Is there any paper or references about this subject?

@fulkrum I was hoping someone smarter than me would reply and point me to some existing research on the topic...