BatmanAoD

To be pedantic, I didn't ask a question, I just said I was surprised! I am still surprised.

Surprised nobody has complained so far about the Rust comparison. I guess any objection would appear to prove the point, or at least reinforce the "evangelist" stereotype.

From your comment, I'm not convinced you do get it. You wrote a lot of words completely beside the point of the joke, which is a series of analogies, not a statement about the natural languages involved in the creation of programming languages.

I wonder what the best programming analogue is for combining words into one where other languages keep them separate; maybe the functional-style chains of adapters?

Ah. Rust's macros and the C preprocessor's exist in vastly different universes. The C preprocessor is literally just a fancy programmatic copy-and-paste tool. Rust macros read the input source code and then execute other source code (the macro definition) to generate new source code that the compiler then reads.

I love Rust, but Rust macros are arguably more of a footgun than compile-time reflection would be, and as amazing as serde is (and no, there's nothing comparable in standard-compliant C++ yet), there's a strong argument that compile-time reflection would be a preferable technique for deriving serialization, argument-parsing, and similar feature.

What macros or attributes provide serialization in C++?

For runtime reflection, no, you'd specifically be able to do things that would be impossible to optimize out.

But the proposal is actually for static (i.e. compile-time) reflection anyway, so the original performance claim is wrong.

If you look at the proposal, this is specifically "static reflection", i.e. compile-time reflection. So it doesn't actually have any of the downsides you mention, as far as I can tell.

I read "happy ___ starts with ___" as stating that happiness was the eventual result of a process that started with ___.

Extension modules can be, and are, written in Rust and C++. And PyPy has a compatibility layer to run extensions (such as numpy) that are written for CPython.

The reason extension modules are typically in C is of course the API is in C, but that's true of cffi as well (though you're right that cffi is more portable). And the reason the API is in C is more fundamental than "CPython is written in C".

The reason C becomes relevant to Python users isn't typically because the interpreter is written in C, but because so many important libraries (especially numpy) are implemented in C.

I'm a Rust fan, and I do think they eventually struck a pretty good "visibility vs noise" balance with ? (which was highly controversial at the time).