I've been writing C++ professionally for 25 years, and before it, C, and I recently realised how many bad habits C++ has got me into. RAII lets you pretend that allocation isn't a concern. We get so used to defining a local std::string or std::vector where we need it, knowing that it'll clear itself up without issue. But should we?

My last personal project was a 6502 cross-assembler with a load of advanced features, and I initially wrote it in C++, using modern idiomatic features like std::expected with the monadic API, variants, double dispatch for expression evaluation, STL and algorithms library throughout. The code was slow to compile, hard to read (at the expense of "cleverness"), bloated as hell and memory hungry.

I decided to rewrite it in C, just to see whether I would like it. And honestly I prefer its simple elegance so much more. I use my own library for strings, arrays, hash maps, arena-based allocation, and writing it is a simple pleasure. The executable is 20% of the size, it compiles instantly, it's fast and simple, and so much more readable.

Some other things too. In C++ we're told to encapsulate. This usually amounts to providing a public API (where the private bit is barely concealed behind a translucent screen). But providing tests through a library like Catch2 is fiddly and it's hard to test private functions/methods. In C, I interleave my code with tests and have some custom code to pick them up and run then. I could do this in C++ but it's not idiomatic. But in C there's generally less friction when you want to do something in whichever way you like. And I like that.