3 ms·

Computers are good at tracking dependencies. It seems silly particularly in this case because Rust is harder to use than a garbage-collected high-level languag

by evmar 10y ago

Computers are good at tracking dependencies. It seems silly particularly in this case because Rust is harder to use than a garbage-collected high-level language exactly because it is trying to squeeze out these last optimizations, and then we turn those optimizations off because it's... what, too hard to automate rebuilding some binaries? It's as if they mandated you write your apps in Python because they didn't want to spend time compiling C apps.

goodplay 10y ago
While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise occur. To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself. However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.ochtman.nl/files/servo-graph.svg https://web.archive.org/web/20160703132700/https://dirkjan.o... Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.
- snuxoll 10y ago
  You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set. Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life. As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.
  - deleted 10y ago
    [deleted]
- evmar 10y ago
  Now I'm imagining Fedora building one rpm per crate in servo -- that picture has like 50 of em, heh.
  - snuxoll 10y ago
    What else is new? Have you seen the package database recently?

by evmar 10y ago

goodplay 10y ago

While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise occur. To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself. However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.ochtman.nl/files/servo-graph.svg https://web.archive.org/web/20160703132700/https://dirkjan.o... Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.

snuxoll 10y ago
You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set. Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life. As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.
- deleted 10y ago
  [deleted]
evmar 10y ago
Now I'm imagining Fedora building one rpm per crate in servo -- that picture has like 50 of em, heh.
- snuxoll 10y ago
  What else is new? Have you seen the package database recently?