There is one advantage to doing OOP in C. Once you figure it out, the mystery of how OOP works all falls away. Frankly, I didn't understand how OOP worked before doing that. None of the tutorials explained what was going on under the hood.
As an engineer, I'm never comfortable using something when I don't know how it works.
While it's hardly a complete object system, perl's bless() operator associating a package name with a data structure, where the package is (for bless()'s purposes at least) basically just a global hash mapping method names to subroutines, was pretty much how I first got my brain around the concept.
I wish more "introduction to OO" things would start by demonstrating a dispatch table and then showing how the vtable concept maps onto that, I suspect it would make things significantly clearer to a bunch of people as they learn.
While other programming languages became mired in OOP dispute, opinion-battles, and all the ensuing problems[1], Perl 5's built-in OO is easy to learn and understand and makes the difficult things simple. It has been stable and effective for decades.
OO is just a pattern; it can be useful or misused, some aspects are more useful than others. But the defining goalposts are moved all the time. They tend to follow the hype machine.
[1] Members of the Perl community know that OO discussions have become harsh there too.
Yeah, I might know a little bit about that, but I was focusing on how bless() helped me initially learn how OO worked at all. (I was after all one of the first power users of Moose, am the original author of Moo and Role::Tiny, and (re)wrote several chunks of the Mojo::Base OO system at various points as well ;)
I'm pretty glad we've mostly standardised on the M* style these days, and Object::Pad (the cpan module that will likely eventually become the template for core OO) is still pretty familiar to users of that as well.
(the days before M* style became the default were ... "fun" ... though at least it meant we got native C3 MRO support added to the perl5 VM to support my decision to use a C3 based component model when I wrote DBIx::Class)
I haven't looked at how the kernel is written. But Linus has a problem using a more powerful language - if Linux adopted one just for OOP, then it will become impossible to hold back contributors from using every last feature of that language. I can understand the reluctance to deal with that.
C++ has plenty of issues, but it's really not that bad, especially modern C++. It's a huge language with tons of features, many of which you'll never use, but as far as writing C++, really not that bad. I've written a lot of C++ over the years, and I've also written a lot of vanilla C. I can tell you that you can definitely get a new project up and running much faster in C++ than in C.
If you are not using classes, you are not using OO at all, by definition.
That does necessarily not mean you are programming badly, although you might be. But restricting yourself to STL and smart pointers does very strongly resemble Java Disease. You might as well switch to Java.
I write Rust too. I like Rust for the mostpart, though there's some issues with the language that really wind me up, mostly to do with the unsafe/safe code boundary.
If you want full control and easier interfacing with the OS, C++ is probably a little better, but Rust is definitely a little easier to work with once you learn the language.
This to me says that C is the more powerful language. C can do what higher level languages can, in not many more lines, but higher level languages cant do the low level things C can do.
This is such a common fallacy. C exposes lower-level memory management, but to then say "oh now you have pointers you can implement anything" is a push.
If you need to implement virtual tables and function pointers, you'd use C++ - there's no need to reinvent the wheel.
Besides software engineering is about focusing on the intrinsic complexity, and using languages and tools to mitigate the incidental complexity.
It's just not worth it. Too much casting, too much scaffolding, much too brittle and error-prone. The experience is like "how much suffering can one endure."
As an engineer, I'm never comfortable using something when I don't know how it works.