Yeah, not to mention interpreted/jitted C++ is a thing (with cling/ROOT). It's very useful to be able to load random shared libraries and do things with them.

The same code can be statically linked into the binaries for those programs, or the code can be loaded as shared objects (modules, essentially).

1. Does it mean that I need to recompile the whole Python or Ruby interpreter each time I want to use MySQL?

2. How am I supposed to load a shared object if there are no shared libraries anymore?

This is literally the question I've asked: is there any other mechanism for achieving 2. other than shared libs?

Shared libraries aren't the same thing as dynamic linking. They're a specific subset of dynamically linked libraries. You can have a single-use .so, and just not install it in the system libs directory.

Windows eventually got this right. There are a set of OS-provided DLLs, that are true shared libraries. Then applications wanting to use other libraries bundle their own DLLs. Applications don't generally need to screw with the system libraries, and shouldn't be allowed to (exceptions for some drivers and similar).

So, basically the mechanism stays the same (after all, .so stands for Shared Object), but the method of using it is different, right? I like your point about system DLLs in Windows.

Dynamic linking is a Windows term (thus .DLL). In Linux (and *BSD) the same concept is know as shared libraries.

If you force everything to be static in a system then yes - You need to statically link everything you need into your interpreter too. Things are going to grow in size a lot (and spinning up your interpreter will take longer time too).

I personally think that shared libraries are the way to go in most cases. And there are distributions which handle this quite well. Of course simplification and general gravity towards minimalism will help too.

Using FFI is extremely handy (very fast to experiment against some dynamic library when the need arises). I personally think your point is perfectly valid.