4 ms·

> What the language really prefers for you to do is to use traits as bounds on generic types to get rid of the dynamic dispatch and the consequent complication

> What the language really prefers for you to do is to use traits as bounds on generic types to get rid of the dynamic dispatch and the consequent complications with lifetimes Isn't this basically equivalent to only using templates in C++ code ? and doesn't it kill build times & prevent reusability across different shared objects ?

kibwen 9y ago
Dynamic dispatch will surely always be faster to compile than static dispatch, but static dispatch has crucial runtime performance advantages (e.g. it enables inlining, which is the ultimate meta-optimization). And extreme runtime performance is one of Rust's raisons d'etre. Having fast compilation is surely a worthwhile goal, but, for Rust, not if it comes at the expense of runtime performance. What do you mean by "prevent reusability"? There's nothing about static vs. dynamic dispatch that prevents code or types from being used across different compilation units.
- twic 9y ago
  > What do you mean by "prevent reusability"? I read that as being about reusing the implementation - the actual machine code bytes which encode a function. If i call a function in library which uses dynamic dispatch, the compiler just emits a few instructions to jump to an existing implementation in the library. If i call a function in a library which uses static dispatch, the compiler will include the relevant monomorphisation of the function, and any other generic functions it calls.
  - kibwen 9y ago
    > If i call a function in a library which uses static dispatch, the compiler will include the relevant monomorphisation of the function, and any other generic functions it calls. Indeed, and that's what precisely one wants if they've chosen static dispatch since the alternative approach is opaque and inhibits optimization. Inlining across compilation units is a rather important feature! I don't see how that prevents reusability, though?

kibwen 9y ago

Dynamic dispatch will surely always be faster to compile than static dispatch, but static dispatch has crucial runtime performance advantages (e.g. it enables inlining, which is the ultimate meta-optimization). And extreme runtime performance is one of Rust's raisons d'etre. Having fast compilation is surely a worthwhile goal, but, for Rust, not if it comes at the expense of runtime performance. What do you mean by "prevent reusability"? There's nothing about static vs. dynamic dispatch that prevents code or types from being used across different compilation units.

twic 9y ago
> What do you mean by "prevent reusability"? I read that as being about reusing the implementation - the actual machine code bytes which encode a function. If i call a function in library which uses dynamic dispatch, the compiler just emits a few instructions to jump to an existing implementation in the library. If i call a function in a library which uses static dispatch, the compiler will include the relevant monomorphisation of the function, and any other generic functions it calls.
- kibwen 9y ago
  > If i call a function in a library which uses static dispatch, the compiler will include the relevant monomorphisation of the function, and any other generic functions it calls. Indeed, and that's what precisely one wants if they've chosen static dispatch since the alternative approach is opaque and inhibits optimization. Inlining across compilation units is a rather important feature! I don't see how that prevents reusability, though?