From TFA, the goal is to "explore whether there's a way we can evolve C++ itself to become 10x simpler, safer, and more toolable". First let's look at "toolabl

From TFA, the goal is to "explore whether there's a way we can evolve C++ itself to become 10x simpler, safer, and more toolable". First let's look at "toolable": My big issue with Modern C++ these days is not just that it's complex to write, but that it also takes a long time to compile, what with all the template/compiler magic going on in the background. Long compile times break concentration, which I don't like. C++2 is not going to improve compilation times, because it's going to be compiled to C++, and then undergo another compilation step. If I combine C++'s slow compile times, two compilers, and all the dumb bugs that I can create and have to debug+fix, I get ....... (pls wait compiling) .......... Let's switch context and look at "simpler": Yay functions look more like JS lambdas or whatever. Fine. Let's look for the pointer-y stuff. Like [1] -- in C or "normal" aka "pre-modern" "C++1" you'd have: int x = 42; int *p; p = &x; func(*p); In the "simpler" "C++2" you have: x: int = 42; p: *int; p = x&; func(p*); I sure hope the changed syntax helps with parsing complexity or whatever, because it's not any different for me. Seems like C++2 got jealous of Rust and wanted to remind everyone "hello fellow kids, C++ is also cool pls". Note that even Rust and Go follow the C-style "*p" pointer deref syntax instead of "p*". What happens if I combine "C++1" and "C++2" syntax in the same file? I'm not as smart as Herb Sutter -- Is "p**x" a pointer deref then a mul? Which variable is being dereferenced? Perhaps it is a double deref, or ...? So much for simpler. (also note I haven't talked about template magicks here) What do we have left ... "safer"? sighs Okay, C is unsafe. Yes, C++ has to carry that baggage. Yes, memory corruption is horrible. Yes, buffer overflow errors lost lots of money, and have caused lots of wailing and gnashing of teeth. Yes, Modern C++ alleviates some of that unsafety with templates and a smart compiler. Yes, Rust has a smarter compiler with better static analysis that helps write safer code. But all this statically analyzed safe code still has to provide C wrappers if it's a shared object, or use the C wrappers provided by whichever kernel it's running on. So somewhere underneath all this safety lurk the familiar monsters, and someone's going to reach for them in the name of performance (remember Actix?). What about all the other issues that you can have unrelated to buffer overflows (log4j)? Will C++2 protect me from my own foolishness? Perhaps that's why its so complicated -- all my C++2 code is safe, because I will write no C++2 code. And another thing: why not just do the Raku or Kotlin thing and call it by a different name, and have it be a separate language compiling to C++? Why "C++2"? Calling it C++2 vs C++ makes me think of Python 3 vs Python 2, and oh man that is not a good connection to hint at when claiming full backwards compatibility. Python 3 also got quite complicated compared to Python 2, so that doesn't give me hope either. Now that I think about it, shouldn't this be called C+=2? TL;DR: - C++2 is not going to be more toolable because ultimately you're still compiling template-heavy C++ - C++2 is not going to be more simpler because unusual pointer syntax, confusion when mixing C++1, template magicks still have to exist - C++2 is not safer because you can/have to still write or interface with C/C++ and the footguns therein. - C++2 should not be called C++2, pls let's find a Raku/Kotlin. Let C++ be the complexity monster it is. That's the tradeoff we make when we have to write it. If safety is the issue, can't we just use a sandbox or something? Is C++2 really the better option? [1]: https://github.com/hsutter/cppfront/blob/main/regression-tests/pure2-lifetime-safety-pointer-init-1.cpp2 https://github.com/hsutter/cppfront/blob/main/regression-tes...