The best way to learn a new language is to follow a proper structured resource which would cover syntax, semantic, tooling & ecosystem and best practices.
I think that's only proper when you have basic understanding of the language. I don't think it is proper to read full c++ doc if you don't even know what is ptr
- new features overlapping old features from previous standards without replacing them or deprecating them (function::copyable_function vs std::function, std::less<> key for transparent lookup in maps)
- new features not usable by the layman (coroutines ...)
- Cryptic syntax (reflection...)
- Stuff you are told not to use because of performance reason and that cant be fixed because of ABI (regex)
- Compile errors that are 1km long (no, concepts are not helping here, the 'nicer' message is still buried into a hot pile of template instantiation callstack).
I wonder how many programming languages would be able to devoid of all or some of these problems when they are 40 years old.
It's easy to compare new and old languages, and saying older languages are wrinkly. Let's see how other shiny programming languages look like when they are 40 years old.
You don't have to use them. There's a handful of nice to haves in modern releases but its totally fine and sane to just ignore whatever the committee is distracted by at the moment.
Hell, if you wait long enough, they'll just deprecate it before you can care to bother.
And that's the usual fallacy (just ignore the bad stuff).
But if you work with C++ in professional context, you will encounter it somewhere (library, teamate's PR, legacy code, LLM output, book / blog / conference ...). |
You actually need to know the bad stuff to be able to judge it and discard it.
Im talking about your own personal coding. You dont have to use the new things. You dont have to know them to decide to discard them. In fact, the criteria to discard something is to not know it. You generally shouldn't be using things you dont know anyway.
The fact that other people use things you do not know is not a reason to stress out about the dumb pace and direction c++ is moving in. It is possible to enjoy a life free from fomo about the c++ standards goalposts.
Concepts support (like traits I'm Rust) is necessary for good diagnostics, but not sufficient. It gives you the architecture and metadata that you require to infer what the user wants, but a lot of additional analysis on the decision chain that was followed in order to figure out what is relevant and what isn't.
Also the C++ 20 "Concepts Lite" isn't a nominal system like Rust's traits (or like the C++ 0x Concepts proposal which Bjarne had ripped out), it's Duck typing again and so it's harder even if the work was done.
Rust can say hey, this code treats Mallard as if it's a Duck, did you mean for this Mallard to implement Duck? If so, try writing #[derive(Duck)]
But for Concepts Lite the compiler needs to guess that you wanted Mallard to match this requirement that Ducks can quack, and observe that Mallard's quack has a slightly wrong signature so it doesn't match and so that's probably the mistake.
We are more likely to have water and food shortages because of resource exhaustion and climate change. Maybe goods shortages because of war or economic depression.
> Dissimilar redundancy eliminates that risk. A completely different OS, different codebase, different development team.
Not entirely true. I've heard during my uni years of a case were two independent teams used the same textbook for implementing a feature, which had an error, and thus resulting in the same failure mode.
reply