Also, avoiding GC pauses while still being subject to interrupts and context switches is a common kind of tunnel vision. Non-GC languages are great for systems programming, but if GC wasn't going to be your biggest source of jitter anyway then using one just means more work and/or more bugs.

This is why those of us who make low-latency systems turn off interrupts and context switches.

Not using a GC does not, in fact, make more work or more bugs, given a language that provides resource management facilities, such as C++ and Rust.

Programs using GC do typically leak, and most GCs make leaks much harder to find and fix. Most GCs even make it hard to determine if you have a leak.

I know you think you're a perfect programmer, but the fact is that most programmers aren't. Of the hundreds, possibly thousands, I've worked with, maybe one in twenty could be counted on to write non-trivial code without introducing new object-lifetime issues that every programmer on that project for ever after would have to keep in mind when interacting with that component. Yes, that includes quite a bit of C++ with RAII etc. but also with threads, callbacks, and ill-fated attempts to avoid copies by using references and move semantics. (C++ RAII is a hack BTW, less a resource management facility than a primitive you can use to build one, always with the sad side effect of forcing programmers to wrap their cleanup code in classes even when it's an ill fit conceptually.) So yes, in practice in real-life teams, manual memory management does lead to more work and more bugs. Only somebody who has never seriously tried to use more than a small fashionable subset of languages could claim otherwise, or that they're not using memory management at all when in fact that's only true for toy programs.

I am ready to believe that you, personally, introduce numerous bugs in code you write, and then blame them on averyone else and on everything but your own bad habits.

But that experience does not generalize. Am I spectacularly lucky in my generally competent colleagues? I doubt it.

Well, apparently you are indeed.

https://docs.google.com/document/d/e/2PACX-1vRZr-HJcYmf2Y76D...

https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-s...

https://support.apple.com/en-us/HT212805

https://support.apple.com/en-us/HT212622

https://support.apple.com/en-us/HT212531

But maybe Apple, Google and Microsoft just aren't able to hire the right kind of highly skilled C++ devs that would write such perfect code, despite having a seat at ISO, and being clang/LLVM contributors.

Apple, Google, and Microsoft all employ very many competent programmers. But they share the problem that they need to hire many more programmers than are both competent and eager to work for them, and so must make do for the rest. It is a much easier task to select a place to work with competent colleagues. Thus, there is no inconsistency.

Perfection is not needed. Ordinary good code suffices. Good code using modern C++, or current Rust, is easier than in older languages (among which count older C++). When bad code is extra work, it becomes an unattractive alternative even to the lazy, leaving its production mainly to the masochistic and the aggressively incompetent, who are often the same.

So the ideal programmer matra that C folks keep stating that has unfortunely taited the C++ community, despite the facts of security exploits and no such people actually existing for the last 40 years.

Here is the thing, when the ISO C++ leaders, and major C++ contributors, push for a change, it is time to start doing some self reflection.

It would help discussion a great deal if you were to actually read what you are about to reply to, and reply to that, rather than just making up something entirely unrelated that you wish had been said instead, and then spouting foolish remarks about something no one has seen or said.

That personal shot was just childish. The moderators chose to ignore the flag, but it was deserved anyway and that's all it deserved.

...not using one...