4 ms·
That’s not really an apples to apples comparison, is it?
by adastra22 1y ago
That’s not really an apples to apples comparison, is it?
- pjmlp 1y agoI dunno why, the missing apple on Rust side is not embracing binary libraries like C and C++ do. Granted there are ways around it for similar capabilities, however they aren't the default, and defaults matter.
- john01dav 1y agoYou only build the world occasionally, like when cloning or staring a new project, or when upgrading your rustc version. It isn't your development loop. I do think that dynamic libraries are needed for better plugin support, though.
- epage 1y ago> You only build the world occasionally Unless a shared dependency gets updated, RUSTFLAGS changes, a different feature gets activated in a shared dependency, etc. If Cargo had something like binary packages, it means they would be opaque to the rest of your project, making them less sensitive to change. Its also hard to share builds between projects because of the sensitivity to differences.
- adastra22 1y agoExcept for RUSTFLAGS changes (which aren’t triggered by external changes), those only update the affected dependencies.
- epage 1y agoI talked a bit about this at the Rust All Hands back in May. A lot of Rust packages that people ust are setup more like header-only libraries. We're starting to see more large libraries that better fit the model of binary libraries, like Bevy and Gitoxide. I'm laying down a vague direction for something more binary-library like (calling them opaque dependencies) as part of the `build-std` effort (allow custom builds of the standard library) as that is special cased as a binary library today.