Otherwise, I have to say that article seems to be more about generating hysteria against C rather than trying to get people to be aware of the issues. What that article paints as being C's evil spewed onto the world (ABI) is actually being used by *every* compiled language, not because it originates in C, but because it has been tuned to the platforms involved. I shudder to imagine the mess if C, rust, etc. all had their own private calling conventions and structure layouts.

All examples given are not wrong, but painted in a way that the difficulty in matching their calling convention is exclusively C's fault and that somehow calling C code can not be avoided. It can, it just may be easier to, say, call into GTK (despite all the pains involved) than write a new toolkit in your new language. The author's first example is possibly the worst: if you want to interact with an OS (make I/O) you need to match *some* convention -- the OS defined one (system calls) or some wrapping thereof (e.g. C). Neither may be easy, but that is not C's fault. The rant about parsing C being difficult is about singling out a specific language and making it look as bad as possible. Firstly, there is no reason to have to interact with C (as mentioned above) and secondly every single programing language is filled with quirks and hard to parse.

The intended humor about a long target list is dishonest at best and manipulative at worst. ABIs are matched to the target architecture (ARM, x86, etc.) not only for performance reasons (e.g. endianess) but also out of necessity coming from inherent differences in how the machines operate (e.g. where return addresses are placed). It can not be avoided, nor is it C's fault. Then there is the historical context that ABIs have been changed at various times to get some more convenient property (e.g. performance). There is no suggestion of what an alternative could be.

The example about opaque structs and symbol versioning is just pain wrong. The whole point of using an opaque struct in an ABI is so you can change the struct without changing the ABI. There is no reason that you have to version symbols and very few libraries do so. Furthermore, if you wish to maintain old and new versions of your APIs, there is no reason to hide them behind symbol versions -- just expose both and the user can select (at their leisure) which one to use so the whole problem explained is side-stepped.

The minidump example tries to shoehorn a problem (fixed binary file layout) into a structure layout ABI problem. Whomever designed it made a choice to carefully have the same structure layout as the file layout, but that is not the only way nor is it impossible to handle if the structure would not match the file layout. Pretty much every function from the windows API could have been used as an example here, with the difference that the hysteria about reserved fields and structure size alignments could not be written.