> it's very imprecise in the way that it defines types.

It's perfectly precise, particularly if you choose to use <stdint.h> which has been available in the language for a very long time. You may have some issues with specific types and platform variability, but it's absurd to cast this as "it's imprecise with types."

It's _flexible_ with types.

People seem to miss that this is the reason why C is the lingua franca. It isn't trying to "perfect" computing. It just makes it possible. There's a lesson for new languages here.

> The complaint is that C isn't the only systems language anymore

C was never the only systems language.

For a long time on UNIX it definitely was, until it got its sibling CFront in the package.

What kind of precision would you like to see added to the way C defines types?

It would be nice if you could just look at an interface and know it returns a 32-bit integer without parsing four C headers to get that information.

C's variables always scale to use the underlying hardware in the most efficient way in terms of performance. There's always sizeof() and macros to get the size of the variables you have.

This is why C is mostly portable with minimum effort unless you do hardware specific things, or use the variable to their limits. In that case you can always define fixed size types.

I don't get why people love to bash C. No language has an obligation to do please the programmer in its default modus operandi. Programming languages exist to interface hardware with humans, and C operates in the realm of the hardware, and that's perfectly OK for me.

No they don’t. If we cared about that we’d be using ILP64 instead of keeping int at 32 bits for compatibility reasons. I’m not here to bash C, anyhow; I think you’re failing to consider that I have experience with C and what it’s not good at, and am able to look past trite statements like “C interfaces with the hardware” that aren’t true or useful. In this case the concern is that C doesn’t make it convenient to talk to hardware!

That is the pitch, but not the reality.

C ABIs (of which there are many because the C standard doesn’t cover ABI) are full of legacy cruft, because they need to be stable and backwards-compatible more than they need to be sensible or efficient.

The C ABI can even vary depending on compiler flags, e.g. availability of AVX affects calling conventions. It’s not easy to be interoperable with this, especially when ABI-affecting compiler flags and macros may be set by an arbitrary build system, not even the C source code.