| From: o1bigtenor via talk <talk@gtalug.org> | > Rust culture and practice doesn't seem to like shared libraries.. I do. | > (Just like I find the update model for persistent containers unfortunate.) | would you please explain the above last statement? 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.