3 ms·
> Come on, guys, jemalloc isn't even in rust and doesn't benefit from static linkage. If you're going to distribute your own runtime (and if you're using your o
by pcwalton 9y ago
> Come on, guys, jemalloc isn't even in rust and doesn't benefit from static linkage. If you're going to distribute your own runtime (and if you're using your own heap, you're distributing your own runtime!) at least distribute it in a shared-by-default way.
Our users consistently indicate that they prefer the convenience of being able to copy all-in-one binaries from system to system to the space savings of dynamic linking. Rust used to dynamically link by default, but based on popular demand this was changed prior to 1.0.
Look at what people say they like about Go, for example. Static linking for easy deployment is high on the list.
- monocasa 9y agohttp://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/
- pcwalton 9y agoI don't agree with this. Dynamic linking is perfectly reasonable for OS libraries like kernel32.dll, for instance. Dynamic vs. static linking is a tradeoff like any other.
- monocasa 9y agoSure, but NT is a totally different story since you just aren't given another stable ABI other than linking against .dlls. But there is a lot of value on Unixen of static linking (or only linking against VDSO equivalents).
- littlestymaar 9y agoDynamic linking is indeed harmful, but static linking also in its own ways. As often, there is no silver bullet, just trade-offs.
- btilly 9y agoOne of the things that I learned from Google is how much breaks on a machine that has somehow corrupted memory in a dynamically linked library. Every application that you deploy using that library is broken. By contrast if you deploy a statically linked application, it probably works. If you deploy to enough machines in the cloud, you'll eventually hit this use case.
- kpcyrd 9y agoIf you deploy enough machines that corrupted memory becomes a common problem you should look at your healthchecks instead of static linking.
- btilly 9y agoYou need to do both. Large distributed jobs at Google can literally take several times the expected lifetime of an average server to run. When you run such a job, you must expect that it will wind up running on computers of all stages of repair, and some of the computers that it runs on will come out of commission during your job and will have to be replaced by others. This scale requires defense in depth. Health checks are necessary, but not sufficient. You also need to minimize the problems if the machine you're on is not yet known to be bad. And deal with double checking results because at that scale you can't trust the hardware. And so on.
- v_lisivka 9y agoIt was popular demand because tooling was not mature. Now we want to install programs, which are written in Rust, using system package manager, thus we demand dynamic linking. Moreover, when part of program is static and part is dynamically linked to a C library, it does not matter any more. For embedded systems, dynamic linking is better when more than one running application is written in Rust, to save memory and processor cache.
- pcwalton 9y agoDynamic linking is fully supported by Rust. Just pass -C prefer-dynamic in your RUSTFLAGS.
- v_lisivka 9y agoBut ABI is not fixed yet, so all libraries and binary must be compiled by same compiler with same options.
- tmzt 9y agoSince the parent mentioned installing using a package manager, could it be default in that case as well as in the `cargo install` case where cargo essentially controls the binary? If not default, could it be more easily chosen with a shorter option? Is a rust heap/runtime packaged for distros like Debian which have packaged binaries of some crates? Note, I'm not in favor of making dynamic default for `cargo build`.