C++ committee members (mainly Boehm, but also Stroutstrup) also deserve a lot of credit for giving us a well specified memory model for concurrency outside of functional languages. Rust basically copy/pasted the C++11 memory model wholesale. Rust's fearless concurrency owes a lot to standing on the shoulders of giants.

Languages have not yet evolved to multi-core properly IMO

I've sketched what I think an ideal "language of today" would look like, and one of the core tenets is making concurrent code explicit and part of the design surface.

You might imagine a webserver with main code like:

  spawn(on_core: 0) {
    await receive_packet(input)
  }

Agreed. I've not liked the contract setup for various reasons. It seems like the proponents of it are mostly there because it scratches an itch in PL PHd studies rather than being an actually useful feature.

I remain unconvinced as why this is a necessary feature over the already existing `assert` statements.

Features are deprecated and removed. It's uncommon but it happens when a new feature makes all use of the old feature unnecessary. Usually it's deprecated for a few versions and then removed some years later. You can always compile old code against an old standard.

C++ does have many ways to do anything. Most of that is historical, or due to features and library facilities with overlapping capabilities, or inherent to multi-paradigm programming languages.

Every C++ project is written in its own language. Its own "house flavor." This is true of all languages, but is particularly stark for a language as old, complicated, and powerful as C++.

Does the existence of PEP 572 not similarly result in being paralyzed and overwhelmed at the number of ways to do something being greater than 1?

C++ definitely has complexity, but I'm surprised by the two examples specifically chosen. Which pointer? C++ only has 2: unique_ptr and shared_ptr (or 2.5 if you want to include weak_ptr but that necessarily means you already chose strong_ptr first). While this might be a complicated choice if you're just comparing to Python, but it shouldn't be if you're familiar with Rust since Rust has you make the same choice.

And then "how should I iterate" is similarly the same as any other language? Either a for or a for-each loop?

There's definitely baggage from 38 years of lessons learned, to be sure, just those examples are odd choices

I share the same sentiment and experience from trying to get into C++. I bought "A Tour of C++" (2022, Stroustrup), I read it back to back, and I thought to myself "it's not so bad, seems quite nice actually, specially the modules part"... oh boy. After 2 weeks writing a HTTP requests CLI tool I was feeling really demotivated, I gave up and went to rust, for no special reason, I just had it queued up after reading "The Rust Programming Language" book.

> pre-LLM, so maybe it's better now?

I came back to the toy tool some time later and used GLM 4.x to implement it further. I had a good experience with it and I understood the code it generated. From my experience, in general, LLM is a good mentor, if you are willing to ingest the content step by step. For me, it is no different from when I used StackOverflow (and other forums) to try and ask how a thing is done.

You're very diplomatic (yet downvoted), C++ is an abomination of a language. It just puts too much accidental cognitive load on developers. I understand that

- it shines for some tasks where Rust isn't capable enough

- it's impossible to get rid of because of all the code so we may as well modernize it

- there's an active community of people who built a career of being C++ experts and have no interest to see the language disappears.

Even in the LLM era, I find it's difficult to code in C++. The language has so many corner cases that LLMs make mistakes. My experience 6 months ago was that the code written by my agent had tons of complex linter warning (exceptions, lambda leaking references, futures whatever... that I just can't avoid because the codebase mixes all of this). Whenever possible, it's probably time to either modernize it or port it to Rust, component by component, until the C++ part is small or inexistant.

You're arguing semantics. The committee owns the C++ standard and its future. It's not pretentious - not having such a governing body leads to either divergence or stagnation, both of which are usually fatal.