The problem the author has is not with the C programming language, no argument here is about some language construct or some abstraction within it, in fact very little about the actual language is said.
To me it is very clear that the issues described do not lie with C(++), the programming language, but with C(++), the language which powers everything from a 8-bit micro controller to the most modern super computer and almost every operating system you can try to put on top of them.
With any language as ubiquitous as C these issues about types had to arise at some point and the reason that most languages "feel" much more streamlined regarding types, is because they never pretend to care about some obscure niche architecture.
The same goes for "C as the language of ABIs", it is a very simplifying choice to have the ABI of your OS be described in the programming language of the kernel. Sure, it does not need to be, but if your language is the layer between software and hardware, maybe it has some right to dictate how you talk to it.
Any language which wants to have a comparable feature set to C in terms of breadth of platforms and depth of penetration will run into issues like this. Maybe it can, with the benefit of half a century of hindsight, make better choices.
A nitpick: please don't conflate C and C++. They're separate languages, this article is exclusively about C, and C++ is an instance of one of the languages that "speaks C". C++ has its own symbol mangling and ABI, which has not historically been nearly as stable or universal.
Virtually every language has a mode to make calls into the C ABI. That's exactly the point of the article.
To switch in to C ABI mode in C++ you have to wrap the declarations in 'extern "C" { ... }' blocks, otherwise you get the C++ ABI, not the C ABI. It's done similarly in many other languages.
I understand the frustration of principled PL authors trying to bootstrap an ecosystem for programs compiled from their language to run on. It can be frustrating having to interact with foreign memory that you don't control and specifications that intentionally leave much to be desired by allowing the hardware platform to decide the memory layout...
But if you didn't have these things it would be a lot harder to get even a basic system going.
It would be nice if there were _one_ standard way to encode an sized integer to rule them all... but we don't live in that ideal world. Pick an arbitrary, common layout, and stick with that. Your language might not let users target some micro-controller that runs on a toothbrush but you probably don't need to anyway.
Right, I dunno why I said layout. If you’re interop is with C libraries then the layout is kind of picked for you. And defined by the platform. Super great times.
> Any language which wants to have a comparable feature set to C in terms of breadth of platforms and depth of penetration will run into issues like this. Maybe it can, with the benefit of half a century of hindsight, make better choices.
I've been saying a variation of this for half a decade now. My version is: the only way to do everything that c/c++ does is to be just as terrible as they are. Replacing them therefore requires a small host of languages in order to do it.
Which is what we're seeing now: D, P, Rust, Zig, Odin, Carbon, Go, C#, Java. They're all slowly chipping away from what we used to need c/c++ to do. I think we probably need one or two more (and then more maturity for several of the existing options) before the process is complete and we're left with a bunch of languages in their own niches and c/c++ in a small niche of their own.
It's perfectly possible to create an ABI standard and have every symbol well defined, a completely specified grammar, and even keep it simple enough so people are able to implement it.
None of the problems on the article are necessary for C to run on microcontrollers and super computers. They all exist because C is an emergent semi-agreement created by people that mostly didn't talk between themselves and meant different things with their words on the few times they talked.
(Anyway, isn't C-- exactly an attempt to do that?)
>They all exist because C is an emergent semi-agreement created by people that mostly didn't talk between themselves and meant different things with their words on the few times they talked.
Sure. But that is pretty much inevitable if you try to get people from a few dozen industries with vastly different goals to try to agree to some form of standard.
You will have to make bad choices, because the good choice is totally unacceptable for one group on the standard committee (maybe for a very good reason).
The problems in C exist because of the vast space of problems it tries to solve. If your programming languages targets x86 and maybe ARM, there is a vast sea of problems you will never have to think about.
>It's perfectly possible to create an ABI standard and have every symbol well defined, a completely specified grammar, and even keep it simple enough so people are able to implement it.
Yes, it is possible but as standard which goes beyond a single system this is about as realistic as people only using "one programming language" and "one operating system".
Any language which wants to have a comparable feature set to C in terms of breadth of platforms and depth of penetration will run into issues like this. Maybe it can, with the benefit of half a century of hindsight, make better choices.