[kccqzy]

> what I hear is a group of scared developers who have been able to coast on their knowledge base for years or even decades

That’s certainly not the case for C++. The C++ language has evolved quickly, with a release every three years or so. One could coast, but they would be writing outdated C++ that no newcomer likes. That is, the entire organization needs to also coast for this behavior to be viable.

Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages in roughly the same space such as Zig or Nim, or occasionally Go. They whine because they think Zig or Nim should take the place of Rust.

[ksec]

>Instead I see most of the bad faith criticisms of Rust coming from aficionados of other languages....

>They whine because they think Zig or Nim should take the place of Rust.

How about because Rust Evangelism Strikeforce go after other language first? Every time a language in the same space comes they get asked if they are memory safe?

Things have died down now, doesn't mean it didn't happen.

[LexiMax]

> Things have died down now, doesn't mean it didn't happen.

I have some bad news for you. In the early 90's, C++ _was_ that language. Not only that, but at the time a lot of the reactionary criticisms of C++ by annoyed C developers had a lot more weight to them.

- C++ was slower than C, because the costs of vtables and exceptions was a lot larger and compilers weren't as good at optimizing.

- C++ was bug-ridden, both because it was easy to accidentally misuse the language, but also because compilers were simply buggy due to the complexity of the language.

- Many of the STL containers you know and love were missing from pre-standard C++, and even afterwards its implementation was commonly subpar, leading developers to either use their compiler-specific proprietary containers or roll their own.

- Streams were often the only reliable thing in the C++ standard library. It also ballooned compile times to the point of being outright banned from many codebases.

- Don't get me started on the utter nightmare that was sifting through compiler errors through misuse of templates...

So yeah, I don't want to hear other C++ developers whine about how annoying Rust developers are. We were just as annoying back in the day, with a worse language. Linus banned C++ from the kernel, and honestly he was 100% right to do so at the time.

[tcfhgj]

> Every time a language in the same space comes they get asked if they are memory safe?

So what?

It might be shocking for you, but every new messenger gets asked if it supports e2ee these days.

Why shouldn't people want to know about the availability of a massive advancement in the space of system programming languages?

[ksec]

And yet at the same time naming Ada is forbidden?

[tcfhgj]

It is not

[LexiMax]

> The C++ language has evolved quickly, with a release every three years or so.

There was a revival of C++ starting with C++11 and ending around the era of C++17. It was, frankly, great. However, a few things happened around and since C++20 that has caused the language to backslide.

First, it seems like corporate support for C++ has dropped significantly. Apple, having successfully replaced GCC with Clang for their own internal use, no longer cares that much about keeping up with the latest C++ features, choosing to prioritize Swift instead. Google seems to have slowed their contributions after being blocked from any commitments that opened up the possibility of breaking ABI. Microsoft has gutted their Visual C++ team, which has significantly slowed the implementation pace of new features and fixing bugs...unless they're related to Unreal Engine. There are also persistent rumors going around that Microsoft are working on their own project in the spirit of rustc-codegen-gcc, but for Visual Studio.

Second, it seems like a lot of the new blood that the revival decade had attracted to the C++ community and standards committee have stopped participating and given up. There's probably not one or two all-encompassing reasons for this, but the disconnected stories I keep hearing about just leave me feeling sad for the future of C++. Anecdotally, the ones that I see that are most commonly cited up are the horrendous rollout of C++ modules, the drama surrounding Safe C++ vs Safety Profiles, and the circling of the wagons around rot13_content_warning("pbaivpgrq puvyq encvfg") Arthur O'Dwyer.

If I had to pick one own-goal in particular that ground my gears from a technical perspective, it's the ordeals of the developer who tried to get `std::embed` into C++. Going through the standardization process was such a nightmare for her - including trying to convince the standards committee that it was a problem worth solving in the first place - that she eventually gave up and took the idea to the C standards committee instead. After a few rounds of back-and-forth feedback, C23 now has #embed. Not only did C get the feature before C++, but the C++ standards committee gave up whatever say they had in the shape of the final product.

That's not to say that I'm not looking forward to certain modern C++ features. Concepts are great, even if they fall well short of the original proposal. I use std::span and std::expected in every project I can, even if I have to use third-party polyfill libraries to deliver them. Modules could be nice when they're more widely supported. But _man_ the future of C++ looks pretty bleak from where I'm sitting, and it seems like the people in a position most able to do something about that future aren't making wise decisions.

[kccqzy]

Agree with a lot of what you said. Definitely to a lot of corporations C++17 was the peak of the language. Apple prioritized Swift afterwards and Google started doing Carbon and begrudgingly accepted Rust.

First time hearing about the embed issue and god that person’s experience is awful: https://thephd.dev/finally-embed-in-c23 and it feels like a job for only the best project managers.