> Yeah, so learning C is required to write a portable C++ lib/extension, so you know what can go in `extern "C"` and what can't. At that point, you might as wel

> Yeah, so learning C is required to write a portable C++ lib/extension, so you know what can go in `extern "C"` and what can't. At that point, you might as well do the whole thing in C and benefit from the super fast compile times. Neither claim there is really true at all. Learning how to write a stable extern C ABI really doesn't require learning C at all, nor even actually using C. Eg, I can put C++ classes in extern C functions just fine, as long as I do so as opaque pointers. Which you need to do for C as well, or use one of the other struct versioning schemes. And then similarly why would I bother with C's nightmare of data structures or error handling in the implementation when I can use C++ instead and have it be a walk in the park? Marginally faster compile times isn't remotely worth it when you're compiling more often to fix more bugs. Finally no you don't need C ABI to have a portable C++ library. You only need a C ABI to have a backwards compatible library as a prebuilt (and even that isn't strictly true, see eg libc++), which is a very very small niche within a niche. Like you're only doing that if you're an OS platform. Everyone else just ships C++ APIs and it works great (eg, abseil, folly, boost, skia, etc...)