> So much time has been spent on making C something that it’s not.

GObject is a great example of this. It's a library for doing OOP with C, rather than switching to C++. It's clunky enough that they ended up making a whole new language which compiles to C/GObject, called Vala.

Vala rarely gets attention these days, but it's worth reading about. https://en.wikipedia.org/wiki/Vala_(programming_language)

Here is another example, COM or as it originally started OLE.

Yes, basically it is C OO ABI, however only masochists would use it as such.

Everyone else just reaches for VB 6, C++ (MFC, ATL, WRL, WIL, C++/CX, C++/WinRT, yeah I know, so is WinDev....), .NET, Delphi, C++ Builder, ...

I have to admit ignorance on exactly what COM does. Doesn't Direct3D (all versions including the latest) use COM despite being essentially a C++-only API?

Yes, they are COM based APIs.

All modern Windows APIs use COM to great extent, anyone that uses pure Win32 APIs is basically frozen in Windows XP view of the world.

Mini-history lesson, initially there was DDE, which allowed for basic IPC on Windows 3.x, then came OLE 1.0, both required endless amount of C boiler plate.

Then someone realized that from all concepts, there was a set of central ideas and Windows OO ABI was born, which basically maps to structure with function pointers, naturally with the same layout as Windows C++ compilers organize their vtables when using single inheritance.

So then we had OLE 2.0, COM, OCX, ActiveX, mini-COM, which are basically all the same, IUnknown interface with three methods QueryInterface(), AddRef() and Release(), everything else builds on top of that.

WinRT/UWP is COM updated with some of the ideas that were actually behind .NET birth, so alongside IUnknown there is IInspectable.

So on Windows any language that understands COM ABI (not only C++) can make use of an OS wide OO ABI.

Then there are lots of things one can do with it, regarding in which memory space those components run, how many threads they use, security,...

Going back to the initial question, it is designed to be called from C as well, but almost no one does it.

I played with this kind of C, and it seems to be attractive to HN. Applying C's own (albeit limited) type-safety and encapsulation features where I can, but not going too exotic or trying too hard to be another language, seems to be the right compromise for me.

9 out of 10 times good old `doSomethingWith(foo: Foo)` style C is better than c++/whatever `foo.doSomething()`.

Contemporary C++ encourages this too. There’s a place for member functions—even convenience ones—but algorithms operate on data structures; they needn’t be part of the data structures.

Since STL was introduced actually, even if functors were a bit painful to write, however if you look at codebases like Android, there is some catch up to do with modern times.