4 ms·

I agree that the C-model is keeping Rust back. But it's ubiquitous and extremely successful. Dynamic linking also practically gives us an ABI (a very simplistic

I agree that the C-model is keeping Rust back. But it's ubiquitous and extremely successful. Dynamic linking also practically gives us an ABI (a very simplistic one) for free, which is great for FFI and debugging. So if I could choose, I'd invest money into a new ABI/linker that reconciles polymorphic languages with separate compilation without demanding a uniform object model. Not only Rust would benefit from such a linker. I have no complete solution for how such a thing might work, but I think it's possible because the actual specializations that stem from monomorphization are very few. It might simply be possible to create one function for every possible monomorphization ahead of time. Even if this turns out to be futile, the actual specialization only needs to change very few things in the code, so monomorphization could effectively be handled by a dynamic linker.

tomsmeding 4y ago
> Even if this turns out to be futile, the actual specialization only needs to change very few things in the code, so monomorphization could effectively be handled by a dynamic linker. This is true in only the simplest case. Already if you have a polymorphic function that sums the elements of an array, you'll be doing function calls to string concatenation if those elements are strings but would really like the vectoriser to produce nice SIMD code when specialised to floats. Specialisation is something that should happen before the optimiser.
- choeger 4y ago
  > Specialisation is something that should happen before the optimiser. That's true, but your example shows a very important point: These cases are limited and (in current languages) known by the compiler developers. I don't know a language that would allow a user-defined datatype to come with such specific optimizations. So for today's languages one could probably enumerate the special optimizations before specialization and then later only dispatch to the optimized code. But even if we say that optimization must happen after specialization, I still think that these optimizations are general enough to be put into a dynamic linker. That's what all JIT engines do, after all.
  - tialaramex 4y ago
    I must not be understanding your idea at all, because it seems to me in both Rust and C++ you can just give user-defined data types completely different behaviour which doesn't occur in any of their built-in types which would be impossible with what you're suggesting.

tomsmeding 4y ago

> Even if this turns out to be futile, the actual specialization only needs to change very few things in the code, so monomorphization could effectively be handled by a dynamic linker. This is true in only the simplest case. Already if you have a polymorphic function that sums the elements of an array, you'll be doing function calls to string concatenation if those elements are strings but would really like the vectoriser to produce nice SIMD code when specialised to floats. Specialisation is something that should happen before the optimiser.

choeger 4y ago
> Specialisation is something that should happen before the optimiser. That's true, but your example shows a very important point: These cases are limited and (in current languages) known by the compiler developers. I don't know a language that would allow a user-defined datatype to come with such specific optimizations. So for today's languages one could probably enumerate the special optimizations before specialization and then later only dispatch to the optimized code. But even if we say that optimization must happen after specialization, I still think that these optimizations are general enough to be put into a dynamic linker. That's what all JIT engines do, after all.
- tialaramex 4y ago
  I must not be understanding your idea at all, because it seems to me in both Rust and C++ you can just give user-defined data types completely different behaviour which doesn't occur in any of their built-in types which would be impossible with what you're suggesting.