Well, he admits he was never very at ease with C++, so I guess he can be forgiven for not understanding very few C++ programmers are going to jump into a garbage collected language. If they were, they would have moved long ago. Most of the times you need C++ nowadays are because a GC language simply won't do.
Kind of silly he drew up his language based on one Google need and thinks everyone using C++ should just jump aboard, though. He acts like he studied why people were writing in C++ and took their use cases into account instead of just his own. Kind of a stereotypical engineer who writes an app for themselves that utterly fails in the consumer market because it is written by coders for coders with weird controls.
Even just reading any of the dozens of long discussions about adding GC to C++ might have been enlightening. It's not like this has not been discussed over and over and over over the last twenty years.
The point being that in any discussion about new C++ features the central point always tends to devolve to:
What is the cost to me if I don't use this feature in my programs?
If I don't use exceptions, I don't pay for them. If I don't use virtual member functions, I don't pay for them. If I don't use RTTI, I don't pay for it.
In other words: If you want/expect C++ programmers to switch to your language, don't make people pay for what they don't want to use.
Support for plugging in a GC would not violate that, but enabling/requiring a GC by default most certainly does.
People use C++ in all sorts of places where having true garbage collection would be better. For example, it's likely used to write the browser you are reading this message on, and possibly the entire OS.
Since far better languages than Go have existed for many years, and those have failed so far to attract many C++ programmers, I just think this is never going to happen until C++ programmers themselves die out.
Using GC in C++ is rather simple, just use a GC-powered allocator and you don't need to call `delete` anymore. But GC just doesn't matter so much. Many forget-to-delete or delete-too-early problems can be solved by memory analyzers. There are actually very few bugs that adding a GC can solve.
This is why I said "true" garbage collection. Conservative GC ain't real GC. GC isn't about eliminating bugs -- use valgrind for that -- it's about increasing programmer productivity, along with all the other features missing from C++ but present in modern strict strong-typed functional languages.
Conservative GC is real GC, it's just the tracing set happens to be the stack. And I don't see why you can't use non-conservative GC for C++ allocators. It only requires some work for read/write barriers.
GC is all about using `malloc/new` without thinking `free/delete`. With modern C and C++ there are a lot of mechanisms for that (passing values, auto_ptr and shared_ptr for example). In many cases a C++ programmer doesn't need to think about `free/delete` either, and in some cases the non-determinism of GC decreases the productivity too.
One of the major (the only?) reason I still write C++ code is the amount of libraries available. I'm writing computer vision stuff and all the important libraries (OpenCV, PCL, nonlinear optimization stuff) are in C++...
Sure there are bindings, but they are often incomplete and not quite stable.
I will switch the day a language allows me to transparently call my existing C++ library, without having to spend time writing and debugging swig/boost::python/whatever wrappers.
Just because some people are using C++ in projects where another language would be better, it does not follow all projects using C++ would be in another language. I have some projects I would hate to do in C++, but I also have projects I would hate to do in another language.
Kind of silly he drew up his language based on one Google need and thinks everyone using C++ should just jump aboard, though. He acts like he studied why people were writing in C++ and took their use cases into account instead of just his own. Kind of a stereotypical engineer who writes an app for themselves that utterly fails in the consumer market because it is written by coders for coders with weird controls.