The author claims to know C++, but remarks suggest she has not learned much, if anything, of it since 1998.
It is possible that her team is similarly not aware, so that it wouldn't matter if she was.
It is possible that her team is similarly not aware, so that it wouldn't matter if she was.
C++ does provide tools to build scalable software, and was already doing so in 1998 (few new features on this front since 98 I guess? Maybe modules, but using them for portable development in 2022 looks difficult given their state in compilers that aren't MSVC). I don't think this is a reason to prefer C++ over Rust (if anything, the tools for encapsulation and modularization provided by C++ are way less convenient and efficient than Rust's--speaking from experience of C++14 and Rust here). Also C++ has the massive drawbacks of lacking ADT, forcing headers on users (which is elaborated in the post I believe) and not offering a "safe mode" like Rust does (the tooling is also massively better, but somehow cargo felt like a hindrance to the author of that post, so there's that).
It did surprise me that the author wouldn't elaborate on why C++ was not chosen, when her argument made it look like it could provide some of the advantages she found in Rust. However, she doesn't *have to* elaborate on every possible subject in that post, and implying she doesn't know the language (anymore) because of her not focusing on the reasons she didn't use it looks like a dubious stretch.
If you don't see C++20 as a very, very different language from C++98, it can only be because you know practically nothing about the topic. That is totally allowed, but expressing opinions based on knowing nothing produces worthless opinions.
Your post comes across to me as more a thinly veiled insult than any sort of useful insight.
Also, nothing in the post lets us infer that the author doesn't know C++11 and later.
- no way to express "lifetime relationships", they remain in comments or force you to work around the problem by using copied objects or worse, shared pointers. This resulted in very real bugs in our code due to a library returning structs that had to live shorter than some other object, without it being clear from the name of the struct. Coincidentally, this same library has a rust implementation, where keeping instances of this struct for too long is a compiler error.
- no blessed way to express thread safety in the type system
- terrible build system without a blessed package manager, which is not about to change because:
- they are still headers everywhere. While modules are technically in C++20, tooling is not ready today (save for MSVC). The module implementation is also dubious in that it seems to cater to any niche use case in existence which adds a lot of complexity (and new opportunities for ODR violations...), instead of going "clean slate" and providing a simple system (preventing the split between declaration and definition and not being orthogonal to namespaces would have been a good start)
- no ergonomic sum types. Sum types are very important to model business logic and it is hard to go back to languages lacking them. There are discussions of pattern matching for C++ but it's not in C++20.
Several of these issues are impossible to fix in an existing language without breaking an unreasonable amount of existing code, so I don't see future versions of C++ reversing the statu quo. I also don't really trust the committee to achieve simple, ergonomic solutions, when I look to eg what was done with modules or coroutines (here I heard that the solution is to use third party libraries, but while it is tractable in Rust it is much less so in C++ due to the lack of satisfying tooling).
You're welcome to elaborate if you disagree though.
Rust has many nice convenience features, but lacks numerous other powerful features C++ provides. But this is not a good place to go into detail. If you care, there is plenty of material online. The point remains that comparisons, if done at all, should be done based on knowledge about current facts, not suppositions and hearsay.
I don't need "thinly veiled insults" when the facts speak for themselves. The author had no need to mention C++ at all. Then, she would not have found herself making ignorant comparisons.
Admitting that each ISO standard is a distinct language (so, C++ 20 is distinct from C++ 17 and C++ 03 and so on) and insisting upon naming them this way would of course satisfy this concern. But doing so would also highlight the uncomfortable reality that C++ 20 isn't a real language programmers can use yet - compiler vendors are still implementing this standard and won't be done for a while. It would also highlight the fragmentation, you would need to pick one of these different C++ languages to write some software, and in doing so rule out using the others.
And that's a pretty poor alternative to Rust, which is one real language Maxime and her team were able to use to write this software.
If it's something like "mastery over most or all facets and nuances", perhaps there are a few thousand human beings in total who meet this qualification. Across all programming languages across the entire Earth.