5 ms·
I’d like to add one: There is too much control at the language level between static and dynamic dispatch. Slimming down your binaries by using dynamic dispatch
by nickysielicki 5y ago
I’d like to add one: There is too much control at the language level between static and dynamic dispatch. Slimming down your binaries by using dynamic dispatch requires significant code changes when it shouldn’t necessarily have to.
I don’t know what I’d propose instead that wouldn’t be just as bad, but I think it’s a wart.
- loeg 5y agoNot sure I agree with this. The relative similarity between static and dynamic dispatch in C++ is pretty confusing (to me) (edit: as in, 'virtual' vs non-'virtual' methods).
- nickysielicki 5y agoOh, let’s not set the bar so low by comparing to C++. ;) Two ends of the spectrum and I think the ideal is somewhere in the middle.
- chubot 5y ago?? They appear completely different in C++, i.e. virtual functions vs. templates https://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic-virtual-calls-vs-static-crtp-dispatch-in-c https://eli.thegreenplace.net/2013/12/05/the-cost-of-dynamic... I also wish they were more similar in both C++ and Rust. I find that most programs get more dynamic as they get bigger, get more usage, and get more extensible ... but the tendency is to want them to be as efficient as possible at the beginning.
- loeg 5y ago> They appear completely different in C++, i.e. virtual functions vs. templates Virtual vs non-virtual functions.
- chubot 5y agoOK there is some static dispatch in regular functions with respect to argument overloading, e.g. f(int) and f(char), or obj.f(int) and obj.f(char). But I think what is more commonly thought of as "static dispatch" is various template programming patterns, as in the blog post, which are more flexible, and has equivalents in Rust AFAIK. Overall it does feel like there are too many similar mechanisms that look extremely different!
- chlorion 5y agoWould a regular non-virtual non-template method be considered single dispatch? I am pretty sure this is correct but I've never actually thought about this until I read your comment!
- pornel 5y agoRust initially didn't require `dyn` prefix for dynamic dispatch (trait object types), but the lack of syntactic distinction was confusing to users. Rust is low-level enough that there is a semantic difference which one you use (Rust calls it "object safety"), so you can't just pretend there's none. Rust is also very focused on performance, and Rust users do care about making such trade-offs consciously. You care about binary size, I may care about inlined autovectorized code.
- pjmlp 5y agoI am perfectly fine not having such difference in C++.
- pcwalton 5y agoI'm not, because of the object slicing problem. Value types and inheritance don't mix well, and the way Rust expresses inheritance with explicit "dyn" traits solves the problem neatly.
- pjmlp 5y agoThat is a point of view, I dislike having to type dyn all over the place, and Impl Something as well, while we are on it.
- deleted 5y ago[deleted]
- nickysielicki 5y ago> Rust is also very focused on performance, and Rust users do care about making such trade-offs consciously. You care about binary size, I may care about inlined autovectorized code. Everyone can agree with this. The question is whether this ought to be a property of the target platform or whether this ought to be a property of the software itself. Rust implicitly takes the stance that it is a property of the software. Suppose we had a chip today that runs poorly due to icache thrash, so you rewrite portions of it with dynamic dispatch. Then someday we get a chip with an insanely large icache that would benefit from static dispatch. You rerewrite it. Or today if you work on embedded linux and want to use a rust library whose primary users are on powerful servers. I will concede that I have no idea whether it’s possible to come up with a reasonable abstraction for this, because you certainly know more than me.
- uluyol 5y agoCan these code changes be automated with a tool? One of the strengths of Go and Java is the ease of writing tools. C++ on the other hand is a mess since it's hard to look through templates (concepts probably help) and macros (good luck).
- pjmlp 5y agoDo just like in Go and Java, use an IDE.
- rami3l 5y agoInstead of enums, how about something similar to Scala's sealed trait syntax to tell the compiler that I'm actually doing a static dispatch?
- zozbot234 5y agoEnums and "sealed" classes enable closed vs. open dispatching. Static (compile-time) vs. dynamic would effectively be devirtualization.