On Thu, Jun 13, 2019 at 02:12:22AM -0400, D. Hugh Redelmeier via talk wrote: > As I understand it, Rust programs are statically linked. Furthermore, > a Rust program tree has copies of "crates" that only get updated when > you ask to have them upgraded (re-imported from crates.io). > > Contrast that with C source. System header files, referenced by > #include in the program, are updated whenever updates are supplied by > the distro and accepted when the sysadmin applies updates to the > host system. Static and dynamic libraries are updated the same way. > > So: if there is an update that fixes a bug, including a security bug: > > - for a dynamic library, a system update will fix the bug in every > binary program that uses it. No re-compilation is needed. > > - for a static library, a system update plus a re-link of each program > that uses it will fix each of them. Recompilation isn't needed but > that isn't often an important advantage. > > - for a header file, a system update plus a recompilation of each > program that uses it will fix the each of them. > > - For Rust: each Rust project must decide to update the version that > is incorporated the crate. I don't know that this is nearly as > automated as Linux distro system updates are. I don't get the > feeling that performing such updates are part of the Rust culture. > Then a project recompile/rebuild is required. > > - for containers: for updates to libraries (or other components) the > container must be rebuilt. This must be done on a system that > itself has been updated. Since there are many container > technologies, I cannot be more explicit. > > Summary: one system-wide update that fixes a shared library, all C > programs on that system are fixed too. This isn't true of Rust > programs. This isn't true of things inside containers. > > On the other hand, bug fixes might make a calling program behave > differently. That change might actually destabilize some system. > Some folks thing stability is more important than bug fixes. > > Also: Rust libraries are young and thus change more frequently than C > libraries. Often for reasons other than bug fixes. This may amplify > the previous argument for stability. > > Windows has suffered from "dll hell" with undisciplined use of shared > libraries. So much so that they often end up not being shared or > updated. But the Unix world, generally, has not. This Windows > experience has given shared libraries a bad name. > > To a certain extent, if you link your C program statically, you can > execute its binary on any Linux distro. This does not work with > shared libraries. > > Shared libraries significantly reduce the size of programs. Rust > binaries are probably quite a bit larger than C binaries.
Go has the same design flaw. Giant static binaries. Amazing how many new programing languages don't want to pay attention to history and the security lessons already learned. -- Len Sorensen --- Talk Mailing List [email protected] https://gtalug.org/mailman/listinfo/talk
