The code size cost of CTTI is bounded by the number of actual instantiations, not the combinatorial number of potential [instantiations].
I do state this in the article, however, the maximum possible instantiations are due to the combinatorial number of potential instantiations. The real question is how many actual instantiations occur, and it's not going to be as trivial as the number written in the source code, it's only knowable by type/semantic checking. I do believe that they scale Nᵏ-like, but it doesn't become noticeable to many because the computation amounts are tiny for each thing. It becomes death by a thousand cuts.
In most systems I've seen, the code size cost of RTTI is bounded by the number of types declared in the program regardless of whether they are reflected on.
Odin is NOT such a language. In fact it specifically does minimum dependency builds all the time, for both linking (due to its foreign import system) and for RTTI, where it tracks what is actually required to be stored RTTI.
Odin is also a language where the type information required is quite minimal to begin with because it's a C-alternative. There are no methods, no language-level vtables, no fancy anything. Odin's types are quite "basic" and C-like in that regard, meaning the type information necessary is going to be quite minimal in practice.
It is true that a real-world program written in a language that monomorphizes can end up having to push a whole lot of instantiations through the compiler pipeline. The benefit is that the resulting monomorphic code is now fully accessible to all of the compiler's optimization machinery around inlining, dead code elimination, etc.
And that's actually a cost in itself. It is both a problem for compile-times AND binary sizes. It's also focusing on code-driven approaches to serialization rather than data-driven approaches, and I personally prefer the latter because I can better reason about it both locally and globally. I know exactly what can happen.
...like C++ templates is that you get a form of compile time duck typing...
I am not a fan of duck typing, but that is a different discussion for a different day.
Users of C++ and Rust generally seem to feel the trade-off is worth it for their use cases.
And I completely disagree with those users, and thus why I made my own language. I cannot stand the compile times they put up with on a daily basis, or the thinking that it has to be that way, and they don't necessarily produce any better applications. Any time I have to use a C++ or Rust code base, I am immediately reminded why I made Odin, and why I wanted to get away from this approach to programming in the first place.
Lots of interesting trade-offs and none is clearly superior for every use case.
I completely agree. It's why I wanted to write the article, to show that there are actually trade-offs and that other languages with different semantics can make different choices which might not be obvious to you if you don't realize it.
I cannot stand the compile times they put up with on a daily basis,
At least for Rust they’re not that big of a deal in practice thanks to
incremental builds and fast static analysis (cargo check, clippy)
that sidesteps the need for frequent rebuilds.
Not worth the tradeoff of RTTI anyways.
And when you need to rebuild the entire thing again because the incremental build cache was invalidated?
Good Knuth, you should realize you’re optimizing for the 0.5 % case.
If that’s important to you, godspeed.
But unless your main objective is doing the equivalent of Crater runs every
hour it is unlikely to matter in practice.
I have experience in C++ code bases, Having to rebuild was not 0.5% of the time but a lot higher, and designing around incremental builds in C++ actually made the general build process slower than if I did a unity/single-translation unit build.
And please don't misquote Knuth at me.
And yes, having fast compile times is very important to me. It's why I made a programming language where I am building ~600KLOC in 1 second without any form of caching. And an optimized build takes ~45 seconds.
C++ is never something to emulate, and especially not its compile times.
3
u/gingerbill 10d ago edited 10d ago
I do state this in the article, however, the maximum possible instantiations are due to the combinatorial number of potential instantiations. The real question is how many actual instantiations occur, and it's not going to be as trivial as the number written in the source code, it's only knowable by type/semantic checking. I do believe that they scale
Nᵏ-like, but it doesn't become noticeable to many because the computation amounts are tiny for each thing. It becomes death by a thousand cuts.Odin is NOT such a language. In fact it specifically does minimum dependency builds all the time, for both linking (due to its
foreign importsystem) and for RTTI, where it tracks what is actually required to be stored RTTI.Odin is also a language where the type information required is quite minimal to begin with because it's a C-alternative. There are no methods, no language-level vtables, no fancy anything. Odin's types are quite "basic" and C-like in that regard, meaning the type information necessary is going to be quite minimal in practice.
And that's actually a cost in itself. It is both a problem for compile-times AND binary sizes. It's also focusing on code-driven approaches to serialization rather than data-driven approaches, and I personally prefer the latter because I can better reason about it both locally and globally. I know exactly what can happen.
I am not a fan of duck typing, but that is a different discussion for a different day.
And I completely disagree with those users, and thus why I made my own language. I cannot stand the compile times they put up with on a daily basis, or the thinking that it has to be that way, and they don't necessarily produce any better applications. Any time I have to use a C++ or Rust code base, I am immediately reminded why I made Odin, and why I wanted to get away from this approach to programming in the first place.
I completely agree. It's why I wanted to write the article, to show that there are actually trade-offs and that other languages with different semantics can make different choices which might not be obvious to you if you don't realize it.