The difference, I think, is that dynamic linking necessarily binds local symbols to the dynamically loaded foreign code, while dynamic loading simply loads the foreign code into the same address space and provides an API for looking up symbols' addresses by name. There's no inherent need for the ABI to match, as long as you don't directly try to call into a function; you can write adapters to explicitly handle the dynamically loaded code's ABI, like python does with ctypes.
At the end of the day it's all machine code running on silicon. What point are you trying to make? I was responding to the claim that a lack of good support for dynamic linking in a language prevents it from using shared objects for plugins and modules. My point was that dynamic loading is an operating system feature implemented through system calls, and can therefore be done in any language that can do a system call, whether or not the language makes it easy for you. I also claim that dynamic linking is not equivalent to loading, but I agree with you that they are related to each other and linking is indeed implemented on top of the system calls that provide dynamic loading. Dynamic linking specifically implies (for me) that non-static application symbols are resolved one way or another before the program counter jumps to main().
First of all, depending on the OS there are no syscalls to call to, Linux is the exception here.
Everyone else has to go through dlopen, LoadLibrary, or whatever alternative the OS offers.
Which is exactly the same code path that at some level the OS dynamic linker relies on.
If you are statically linking everything, then there are no libraries to give input to dlopen anyway, it doesn't load .a files, and .so is not what we want to support anyway.
But lets keep the assumption that in the world of static linking advocacy, explicitly loading dynamic libraries is acceptable.
SO now, not only has the application to do the job of mapping dynamic library symbols to function pointers, they are constrained to C ABI function calls, which is not Rust anyway.
As for you Linux based assumption, there are OSes, where dynamic linking doesn't take place before the PC jumps to main, you can do deferred dynamic linking. The call sites are marked for triggering a page fault on call, which only when it happens, will the OS look around for code to load.
This is how managed languages like Java and C# work, which many keep forgetting there are also AOT compilers, just in case the VM arguments comes into play.
But since we are talking about systems languages, you can find this feature on Windows and Aix, just to give two examples how the OS world isn't everywhere a Linux clone.
Just dropping by to say that you're right. You can absolutely _load_ dynamic libraries from Rust. I've done this. But of course, the executable is not dynamically _linked_ to the requested libraries. E.g., running `ldd` on my executable won't show which shared libraries it is or should be linked against. Rather, it will just fail with an error if the requested library is not there. There are crates for loading dynamic libraries that use `dlopen` under the hood.
In abstract you could separate these things, but in modern OSs there is little to no difference between these concepts. Dynamic loading is implemented using dynamic linking and if you don't want to use dynamic linking then you have to reinvent the wheel down to the OS level. You will have a very hard time to make dynamic loading available in any architecture following this route.
