> I think you have the best intentions, I believe what you are describing is also the exact meaning of FUD. FUD usually has a negative connotation as a disinge

> I think you have the best intentions, I believe what you are describing is also the exact meaning of FUD. FUD usually has a negative connotation as a disingenuous form of rhetoric. If your assume the poster is genuine, then you shouldn't in the next breath accuse them of spreading FUD. If one is genuinely fearful and uncertain and filled with doubt, it's okay to express that. To the parent's point, C++ does allow programmers to easily write code that crashes spectacularly. Such bugs have been shown to cause catastrophic failure in critical systems, to the point where we decided to build languages and tools that mitigate those modes of failure. Those learnings have found their way back into C++, but the problem remains that writing modern C++" is an ever-moving target, and the "legacy C++" that should be avoided is still there in the name of backwards compatibility, so buggy code still being written. The solution is not "just write modern C++" because that doesn't work; witness the lamentations here about people who are still writing C++ like it's the 90s. As for the uncertainty, the only problem with that statement is the "probably" because we all know the only bug-free code is trivial code (and even then...). But still, there's an important point here: shouldn't we be able to confidently make statements about our codebase like "there are no bugs of X type in here, because it's been checked by tools". For example, some languages are stricter with what they will allow past the compiler, and the level of strictness confers some guarantees about what kind of bugs have been checked. If we can't say "my language's tooling makes it so my program doesn't suffer from X bugs", then how much is it helping us really?