> Behind that function call, behind that nested expression and that "p = malloc(sizeof(*p))", etc. there might be extra complexity for the sake of developer's readability and comfortability.
There is no way to avoid most of things you listed. It's not comfort; it's a necessity.
> software written in C is generally such a shitshow
Whatever language you use to code, all your calls will sooner or later pass through a function call, a nested expression or a malloc()/free() call, somewhere in the huge stack of C code your language needs, depends and relies on. There is no escape. Basically, today your preferred language exists and might be able to something just because C code exists.
> There is no way to avoid most of things you listed.
Oh yes, there definitely is: There are no function calls, nested expressions, or malloc in assembly – those are abstractions provided by the language and translated by the compiler, for comfort, not necessity. In fact, you can simulate all that in C itself: use gotos and an explicitly managed memory area as stack, and manually transform nested expressions into SSA form.
You are still paying for the register allocator. That is not a trivial abstraction; it is wildly complex and carefully tuned, and there is ongoing research on how to do it better.
There is no way to avoid most of things you listed. It's not comfort; it's a necessity.
> software written in C is generally such a shitshow
Whatever language you use to code, all your calls will sooner or later pass through a function call, a nested expression or a malloc()/free() call, somewhere in the huge stack of C code your language needs, depends and relies on. There is no escape. Basically, today your preferred language exists and might be able to something just because C code exists.