I largely agree and personally hate working with dynamic linking, but ultimately it depends on your architecture model - to share memory, or not to share memory

I largely agree and personally hate working with dynamic linking, but ultimately it depends on your architecture model - to share memory, or not to share memory. If you've already decided you don't want to share memory, and you don't want to use system IPC, that leaves you with sockets (network/unix/fifo), which are all just byte streams. If you have byte streams, then you gotta use (de)serialization (serde) on either end, so effectively there is one ABI: {uint8[], size_t}. This is the microservices/docker/cloud model, and it's great. For many purposes. But if you are dealing with OS level stuff, talking directly to hardware, in the embedded space, etc, now you care about different ABIs for performance reason. Now you decide, do I want static linking or dynamic linking? The only place I see dynamic linking really being a feature is when you have to link against the kernel, drivers, or proprietary subsystems (e.g. CUDA). IMHO, most userspace application layer stuff shouldn't be sharing memory, it should be communicating, again using byte streams and serde. So that basically leaves the hardware/software interface: kernel APIs, drivers, etc. If you're in this space, great, it makes sense to use dynamic linking with very stable ABIs with no generic shenanigans, you don't need them. I think a lot of pain of DLL hell comes from using dynamic libs when you really should be statically compiling if it's a library, and IPC if you need to communicate.