I agree with your non sequitur, but I think there is something there nonetheless.

I think Yossi Kreinin's main objection is not the absence of garbage collection in C++, but the fact that so many projects that could use garbage collection, don't.

Like "I need performance!" No you don't. "I really need performance!" My GC is just as fast as your malloc/free. "I don't use malloc/free, I have my own custom allocators, you ignorant Java programmer!" I just use manually managed arrays for that, and enjoy garbage collection for the rest of my data. "My environment can't afford me any GC pause!" My GC hardly pause, and it collects gigabytes of data. "But I know things about my data your GC don't!" OK, now you may have a point.

The performance difference between C++ and a well implemented native language with garbage collection (OCaml, Haskell, Lisp, Go…) is not large. Definitely less than an order of magnitude. Your constraints must be real tight to force you to give up garbage collection.

In the vast majority of projects, not using garbage collection is a problem. If not with the language, at least with the community.

---

I think Yossi Kreinin don't object the knife itself. He objects the fact that people actually try to eat soup with that damn knife, spilling soup and cutting their tongue in the process. Sometimes, we do need sharp edges (for cutting meat). But for much eating activities, sharp edges are just a hindrance.

Not really. It says that having garbage collection is a design choice. What it presents as defective are the implementation of operator overloading and exceptions, and says that having garbage collection would have been a good way to avoid these being defective.