I agree with the point regarding C++&#x27;s spec, but don&#x27;t fully buy the point about C&#x27;s spec. C&#x27;s spec is surprisingly succinct. C code written to spec is not harder to think about than any other language I have worked with. I have had as much trouble getting my Python&#x2F;MATLAB&#x2F;Julia code to dance the way I want it to as I have with C. What is different is that if you get it wrong, all hell breaks loose in terms of security issues.<p>Regarding the wrappers behind unsafe behavior, in addition to some of your ideas, a lot can be done even in C, see e.g netstrings <a href="http:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;netstrings.txt" rel="nofollow">http:&#x2F;&#x2F;cr.yp.to&#x2F;proto&#x2F;netstrings.txt</a>, and other safer interfaces. It requires thought, but such thought needs to be devoted in designing other languages. Unfortunately, the C&#x2F;C++ standards committee rarely accepts such slower, safer extensions, forcing clients down the dark road of third party libraries and the endless choices available there, some of which are horrible and actually worse than the stdlib. I believe a lot of the problem is that there is heavy disagreement as to what interface is best, see e.g strlcpy and its adoption. Getting a large committee on board with solving something is a monumental problem, even if all acknowledge that the current situation is terrible :).<p>&quot;Best results&quot; is a very loaded term, and I tend to avoid it due to the large number of dimensions to it, the most common being the classic performance and security axes. Nevertheless, we mostly agree on the key points, with some differences in the details.<p>TL;DR: I have not found something representing a Pareto improvement over C. All improvements tradeoff some aspects, and it is thus sometimes not clear that there is a better alternative to C. My stronger claim is that the above is true even if one ignores legacy issues.