[jononor]

Agreed in general on using C++ over C, or C-style C++ in constrained environments. One thing that is nice about using C though is that it is quite easy (compared to C++) to expose to other languages. Glib, and most libraries built on it like GTK, GStreamer, etc can be used in languages such as Python, JavaScript et.c.. And a lot of development of applications and tools has been moving to such languages over say C++. So C is still useful for low-level libraries, due to being the lowest common denominator. Though arguably one could today write the library core in a better language like Rust maybe, and expose a C API/ABI from that. Rsvg is growing into an example of that.

[samus]

C++ seems difficult to embed because there is no standard way to expose features that don't map well to the C calling convention. Just use `extern "C"` if you want a C API. For everything else you'd have to commit to an application binary interface first, such as GObject, COM or the CLR. You need these to define calling conventions and semantics (such as initialization, exceptions, memory and resource management) well enough that other languages can bind to them.

[pjmlp]

I look forward to it eventually to grow into OS vendors SDKs, at very least those that provide llvm based toolchains.

Until then C++ will do.

[jononor]

Do you mean glib? It is in every server and desktop Linux distro, including those with commercial support from RedHat, Canonical and SUSE. For embedded Linux devices glib is included in Ubuntu Core from Canonical, as well as Wind River Linux from Intel. The GStreamer SDK includes glib and is supported by Fluendo and Collabora on Android, Windows and Mac.

[pjmlp]

Not at all, I mean Rust being available alongside C and C++ on OS SDKs, regardling tooling, IDE and libraries.

A checkbox on the installer, with first party support.