I'm not sure who first coined this idea or put it in a book or where I've read it, but for code comments I generally like the "explain why, not what" philosophy. The "what" is answered by the code itself and should be easy enough to comprehend if your design is simple and your names meaningful. The "why" is much more important. Why does this parser check for some magic numbers at this specific offset and change some parameters if it finds them? If you don't explain that its because of e.g. compatibility with some legacy format, its gonna be a mystery to the reader.

You don't need developers with 20 years of experience in a specific language.

Any decent engineer must be able to work with other languages and tools. What you're looking for is someone with experience building systems in your area of expertise.

And even then, experience is often a poor substitute for competence.

We do use clangd and it provides many checks, but I wanted to include clang-tidy in the CI. Though since me and my colleagues combine ff-only and ‘must build successfully before merging’, adding like 5 minutes to the CI is really annoying.

Iirc the reason why clangd is so much faster than clang-tidy is that clangs omits certain checks and limits which code it analyzes.

>[...] this will depend on who you ask, e.g. some C++ developers don’t mind Rust’s compilation times at all, as they are used to the same (or worse) build times

Yeah pretty much. C++ is a lot worse when you consider the practical time spent vs compilation benchmarks. In most C++ projects I've seen/worked on, there were one or sometimes more code generators in the toolchain which slowed things down a lot.

And it looks even more dire when you want to add clang-tidy in the mix. It can take like 5 solid minutes to lint even small projects.

When I work in Rust, the overall speed of the toolchain (and the language server) is an absolute blessing!

I dont think we should fine any of the people that worked on it. In the end the decision makers are the ones being paid to be responsible so they should be held responsible.

However, there is a conversation to be had about engineers writing code that they fully know is illegal. Imo there should be a punishment for staying complicit and not reporting it to the authorities. Like that time Volkswagen components detected when they were under test and performed differently.