4 ms·

> Recognizing that generic libraries are only called with a single concrete type is child's play in those contexts. It's pretty trivial to prove this wrong. Re

> Recognizing that generic libraries are only called with a single concrete type is child's play in those contexts. It's pretty trivial to prove this wrong. Return a different concrete type based on a config value that is loaded at startup. AOT can't save you here. We can keep moving goalposts but it shouldn't stretch the imagination that a program's runtime characteristics can't be exhaustively predicted at compiletime. This is sort of like claiming that branch prediction isn't useful because can't you just throw away what's unused? No, obviously not, so if the branch exists, runtime analysis can find out which one is more likely to be called over time (and generics are just a branch at the type level).

hansvm 4y ago
The person I was responding to said that AOT was a non-starter because the tech I mentioned doesn't exist, and that itself was in the context of a domain where you often wouldn't want the perf hit of even having a poor program binary layout and thus probably wouldn't want such things to be config options anyway. In any event, I was just saying that AOT can definitely cross library boundaries, not anything near as strong as what you seem to be arguing against (it seems you believe I'm asserting something like AOT being superior to JIT in all cases).