Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 10:25 UTC (Tue) by intelfx (subscriber, #130118)
In reply to: Shared libraries by taladar
Parent article: APT Rust requirement raises questions

> I mean lets be honest, if Qt were a Rust library it would also be much, much smaller because it wouldn't re-implement an entire ecosystem of dependencies inside the library itself the way it currently does in C++.

It would have been smaller in source code, but not in binary, for obvious reasons: it might not need to reimplement an ecosystem of dependencies, but the object code generated from those dependencies would still have to exist somewhere.

Unless, of course, it was a hypothetical *shared* Rust library, linking to *shared* Rust libraries of those dependencies. Right.

to post comments

Shared libraries

Posted Nov 26, 2025 16:25 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

Qt is a "kitchen sink" library which tries to offer everything you might need, so it's hard to compare, maybe a Rust Qt-like would insist on offering all these container types Rust already provides for example, just as Qt feels the need to supply QList (the growable array type) QStack (the same type, with a more stack flavoured API) and QQueue (the same type again AFAIK but now used to back a ring buffer abstraction presented as a FIFO Queue)

C++ doesn't provide very good container types, but it does provide a reasonably good growable array type, with the expected amortized constant time growth, the basic reservation feature - and QList isn't actually better. So the fact QList was provided anyway suggests the same mindset would apply in Rust for a library in that mould.

But on the other hand, a library which didn't insist on offering its own version of things you already have might actually reduce the redundancy and the extra marshalling overhead from the duplication, so that might actually be a net win in size terms.

Shared libraries

Posted Nov 26, 2025 17:19 UTC (Wed) by excors (subscriber, #95769) [Link]

> C++ doesn't provide very good container types, but it does provide a reasonably good growable array type, with the expected amortized constant time growth, the basic reservation feature - and QList isn't actually better. So the fact QList was provided anyway suggests the same mindset would apply in Rust for a library in that mould.

Back in 1998 they explained: (https://github.com/KDE/qt1/blob/25d30943816da9c28cded9ac7...)

> Qt's containers are much more portable than the STL is. When we started writing Qt, STL was far away in the future, and when we released Qt 1.0, no widely-used compilers could compile the STL. For a library such as Qt, it is of course very important to compile on the widest possible variety of compilers.

They also justified it by having different space/time tradeoffs to STL containers (and still make that argument in today's documentation); but if the STL had been widely available with decent-quality implementations when they started, I imagine they would have simply used that and put up with its other limitations. And anyone starting today in Rust would simply use Rust's std containers.