> If you're given license to finally rewrite that [C++03] code to modern standards
Then you aren't choosing C++20-something, you're choosing a new language altogether.
This is why the demand for C++ devs is dropping - if you're going to bite the bullet and rewrite, why not choose a better language, preferably with GC?
> It's not like C++20 is completely different. There's just a lot more utilities in the stdlib so hopefully less raw pointer magic.
What was best practice for C++03 is not the same for C++20.
Switching a codebase from C++03 to C++20 for a nontrivial codebase means changing design so radically it may as well be a new project, rewritten from scratch.
It'd certainly be easier to rewrite in C++20 for the C++03 projects I've recently worked on, than to try to squash in a C++20 design.
- Immature compiler susceptible to generating performance traps
- Build times even longer than the infamous ones in C++
- Simplistic declarative-based build system
- Inability to opt-in or to opt-out from static analysis
- Harder to scratch up quick PoCs because borrow-checker
- More complicated compilation model making it harder to understand, debug and implement workarounds when codegen goes south
- Much smaller ecosystem - libraries, toolchains, tools, ...
- False sense of security - by default it relies on the ecosystem whose runtime and its OS is implemented in "unsafe" languages
- Cannot even live to its "safety" promise because hardest problems cannot be solved without unsafe sections
I sincerely wish it was different but at this moment I am not convinced that Rust trade-offs are worth switching to it. This is the PoV coming from a system-level programming, very close to the OS, and with a lot of difficult memory and concurrency scaling issues.
Then you aren't choosing C++20-something, you're choosing a new language altogether.
This is why the demand for C++ devs is dropping - if you're going to bite the bullet and rewrite, why not choose a better language, preferably with GC?