[the_why_of_y]

The Glib+Gtk world chose to limit itself to a C ABI, which makes it far easier to interop with other languages than C++ as used by Qt.

This is the case both for statically compiled as well as dynamically interpreted language implementations; the latter can use automatically generated bindings via gobject-introspection, which has no equivalent in the Qt world, where all language bindings are hand-crafted at great effort.

https://gi.readthedocs.io/en/latest/

It also means that the implementation behind the ABI can be replaced with a different language such as Rust, as has already been done with librsvg. On the other hand, Qt will forever be stuck with legacy C++ language, which appears designed to be nigh impossible to interop with.

And if you have a requirement to use C++, there is the gtkmm binding too, which doesn't require a separate language extension such as Qt's MOC to use.

https://www.gtk.org/docs/language-bindings/cpp/

[Asooka]

Qt can trivially offer a C ABI if they want. Glib can't be type safe no matter how hard they try. People don't seem to have any trouble making Qt bindings for languages like Go, Python, Java, all of which you could say strongly prefer interop with C. Part of the reason is that Qt is written in a way that avoids use of more exotic features and templates for most things. MOC could be replaced by template magic nowadays, but I don't see any value in doing so - you will just make compilation slower and bindings with other languages harder.

[baybal2]

Well, I mean they could've moved up to more recent standards well within the C world.

As of now, Glib doesn't even utilize much of C99.