[whytevuhuni]

> > no dynamic linking

> There is.

Eh, I'm a Rust fan, and I hate the dynamic linking situation too.

I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous.

The only shared library support we have now is either using the C ABI, which would make for a horrible way to use Rust dependencies, or by pinning an exact version of the Rust compiler, which makes developing for the system almost impossible.

Hopefully we'll get something with #[export] [1] and extern "crabi" [2], but until then Rust won't be able to replace many things C and C++ are used for.

[1] https://github.com/rust-lang/rfcs/pull/3435

[2] https://github.com/rust-lang/rfcs/pull/3470

[koakuma-chan]

> I genuinely cannot see how Rust would be able to scale to something usable for all system applications the way it is now. Is every graphical application supposed to duplicate and statically link the entire set of GNOME/GTK or KDE/Qt libraries it needs? The system would become ginormous.

You don't have to statically link C libraries.

[whytevuhuni]

I am referring to Rust scaling up to where C is now (i.e. try to remove C from the picture).

As in, if there will ever be a Rust equivalent of KDE/GNOME (e.g. maybe COSMIC), it will have similar libraries. They will have to be in Rust, and will have to be statically linked. And they will eventually grow up to be the size of KDE/GNOME (as opposed to the tiny thing COSMIC is now).

[ryao]

If it is any consolation, early C did not have dynamic linking either. It was added afterward. From what I understand, UNIX systems had statically linked binaries in /bin until ELF was introduced and gradually switched to dynamically linked binaries afterward.