It does support dynamic libs, but virtually all important Rust software seems to be written without any consideration for it.

Rust ABI (as opposed to C ABI) dynamic libraries are incredibly fragile with regard to compiler/build environment changes. Trying to actually swap them out between separate builds is pretty much unsupported. So most of the benefits of dynamic libraries (sharing code between different builds, updating an individual dependency) are not achieved.

They’re only really useful if you’re distributing multiple binary executables that share most of the underlying code, and you want to save some disk space in the final install. The standard Rust toolchain builds use them for this purpose last time I checked.

Yep that’s right. I’ve been working on a game with bevy. The Bevy game engine supports being dynamic linked during development in order to keep compile times down. It works great.

Rust does support C ABI through cdylib (as opposed to the unstable dylib ABI). This is used widely, especially for FFI. An example of this is Python modules in Rust using PyO3 [1].

[1] https://pyo3.rs/v0.15.1/#using-rust-from-python

Yeah but you can’t use the vast majority of crates that way. You have to create a separate unsafe C ABI, and then use it in the caller. Ergonomically, it’s like your dependency was written in C and you had to write a safe wrapper.

C++ has the opposite problem where people think they can just dynamically or statically link against any api be ok. You can’t cross the ABI barrier without a) knowing it’s there, and b) respecting its rules.

You get lucky when all assets have been compiled with the same toolchain (with the same options) but will lose your mind when you have issues caused by this thing neither you nor the package authors knew existed.

People thinking C++ libraries magically solve this ABI issue is the other side of the coin. I’ve filed numerous bugs against packages precompiled libraries but misusing the C abi so that (owned) objects cross the abi barrier and end up causing heap corruption (with a segfault only if you’re lucky) and other much more subtle heisenbugs.

the rust abi is explicitly unstable. there are community projects to bring dynamic linking, but it's mostly not worth it.

That is not correct. Dynamic linking is natively supported in Rust. How else do you make modules for scripting languages like Python (using PyO3) [1]? It uses the stable C API (cdylib).

[1] https://pyo3.rs/v0.15.1/#using-rust-from-python

RAM is cheap mmmkay?

Or at least it used to be when they designed the thing…

Is it a RAM problem though? My understanding is that each process loads the shared library in its own memory space, so it's only a ROM/HDD space problem.

If you stop using shared libraries each application will have its own copy in ram…

The problem is vulnerable dependencies and having to update hundreds of binaries when a vuln is fixed.

Go definitely supports dynamic libraries

I don’t mean Dylibs like you find on macOS, I mean loading a binary lib from an arbitrary directory and being able to use it, without compiling it into the program.

It’s been some time since I looked into this so I wanted to be clear on what I meant. I’d be elated to be wrong though

Both handle that just fine. Go does this via cgo, and has for over a decade.

You do still need to write the interfacing code, but that's true for all languages.

Then by that argument Rust also supports dynamic linking. Actually it’s even better because that approach sacrifices less performance (if done well) than cgo inherently implies.

Well, Rust does support dynamic linking. It just doesn’t (yet) offer a stable ABI. So you need to either use C FFI over the dynamic linking bridge, or make sure all linked libraries are compiled with the same version of the rust compiler.

It was built to do that, yes

Go supports plugins (essentially libraries) but its has a bunch of caveats. You can also

You can also link to C libs from both. I guess you could technically make a rust lib with C interface and load it from rust but that's obviously suboptimal

The dynamic libraries that use the unstable Rust ABI are called `dylib`s, while those that use the stable C ABI are called `cdylib`s. Suppose a stable version of the Rust ABI is defined, what would be the point of putting dynamic libraries that follows this API, in the system? Only Rust would be able to open it, whereas the system shared libraries are traditionally expected to work across languages using C ABI and language-specific wrappers. By extension, this is a problem that affects all languages that has more complex features than C. Why would this be considered as a Rust flaw?

> if I recall correctly Rust does not support any form of dynamic linking or library loading.

Rust supports two kinds of dynamic linking:

- `dylib` crate types create dynamic libraries that use the Rust ABI. They are only usesul within a single project though, since they are only guaranteed to work with the crate that depended on them at the compilation time.

- `cdylib` crate types with exported `extern "C"` functions; this creates a typical shared library in the C way, but you also need to implement the whole interface in a C-like unsafe subset of Rust.

Neither is ideal, but if you really want to write a shared library you can do it, it's just not a great experience. This is part of the reason why it's often preferred to use scripting languages or WASM (the other reason being that scripting languages and WASM are sandboxed and hence more secure by default).

I also want to note that a common misconception seems to be that Rust should allow any crate to be compiled to a shared library. This is not possible for a series of technical reasons, and whatever solution will be found will have to somehow distinguish "source only" crates from those that will be compilable as shared libraries, similarly to how C++ has header-only libraries.