Honestly, I hate includes and preprocessor directives so much that any "better C" variant which replaces them with more modern solutions would probably be enough in my book - with the caveat being that I also like having an IDE very much and wouldn't want to revert to coding in something like emacs with plugins. BTW, C++20 has a good replacement for includes (modules), but IDE support is not there yet and thus it's not usable for me.
I wholeheartedly agree, the speed of processing includes annoys me most about C.
The sad part is that the mainstream alternatives that I have on the radar are _even slower_ to build.
And usage of the preprocessor in APIs is allowing for good things, at least for a compiled systems language like C: Macros allow to get rid of boilerplate on the syntax level and if-defs allow for compatibility. Both points' significance is reduced a long way in other languages, because they have stronger facilities for abstraction, BUT this abstraction comes at a non-significant price and cannot replace all significant uses of the preprocessor.
So I'm still stuck with C. The solution is designing header files carefully, resulting in build times that are lightning fast, at least in relation to most other mainstream languages. And there is always the option to go for "unity" builds.
What bother me most is not even the speed of compilation (although it's a major pain too), but the fact that I need to create a header file for every .c file I want to have used from outside it's compilation unit, and add method declarations in it. In 2022 it's SO BACKWARDS it hurts.
I almost never found that painful. Maybe a couple things that help: 1) Improve modularization. APIs should be small (as a rule). 2) Don't write a new file for each "class". It's not a problem to have files with more than 1 KLOC. But it is problematic to have a lot of really small files, as is (I think) customary with say Java.
I come from the Java world, so I'm very used to every semantically separate bit of code sitting in its own file. I think it's superior to having multi-KLOC source files (as is common in C/C++ world, because it minimizes the header writing and maintenance busywork), because then you can browse code via a file browser, which is typically a panel in your IDE. The C alternative to that would be having the same file opened in multiple tabs, and heavy usage of (IDE) bookmarks? I don't find that as convenient.
As to improving modularization, in order to fix compilation speed issues I was trying out the "program as a single compilation unit" approach advocated by handmade people, and I found that I had to spent a good amount of time in moving code between modules, and their subsequent headers. So annoying... Perhaps it wouldn't be so infuriating if I didn't spend the past 15 years coding in languages where this is a problem solved automatically and invisibly by the compiler.
