No, the specific problems are not linked directly to OOP/GC, but the fact that universities and employers push languages like Java without teaching the coders how to actually design programs first does cause that type of problem. It's so easy to make a gargantuan dogpile in Java or C++ that unless the coders actually blocked it out and analyzed it, they're likely to just cause problem after problem when they add more code to address the symptoms.
I'm certainly not going to defend C++ in any way; my attitude is that if C++ is the answer then exactly what was the question.
The gargantuan dogpiles that can accrete in Java are
because of its success in avoiding many of the problems in C/C++. Essentially avoiding the problems has allowed run of the mill programmers to make much larger programs than is practical in C/C++.
As for not teaching how to design programs, t'was ever thus. Some people should never be allowed near a keyboard or a soldering iron!
The "memory leak" issue comes from people writing spaghetti code or using libraries with unintended side effects, and not caring or knowing that they have to be aware of memory usage in spite of GC. Many of the problems we saw in production were the GC kicking in at a very bad time and grinding the programs to a halt because the programmers didn't bother to understand or stress test the code before submitting it to production. Everything to do with bad design and very little to do with the language - except that Java and its ilk are not taught along with proper design techniques (at least among the programmers we worked with at AT&T). I tended to write procedural Java (much despised by "real" OO programmers) but because I knew where memory was being used and for what, my code didn't have those issues; it may have run a bit slower at a guess, but it never crashed.
I wasn't clear enough. My objection is calling "data cancer" a "memory leak".
And it is well known that you can write Fortran in any language
![Smiley :)](https://www.eevblog.com/forum/Smileys/default/smiley.gif)
So my point was that languages like Java and C++ typically exhibit issues because the programmers aren't taught good techniques, and those languages are likely to be used a lot by inexperienced programmers IME who are too lazy to code wisely. They're also hard to use efficiently by fledgling programmers. Heck, I used Java for 16 years and never got familiar enough with it to be aware of all the pitfalls. C, on the other hand, is so easy to master that I think I understood it fairly well.
As someone that first used C when there were precisely
two books on the language (i.e. in 1982), I am only too well aware of how people think they know the language - but don't. C++ is even worse, and is beyond being salvaged.
Java is a much simpler language in that it has fewer gotchas - there's no need for "language lawyers", for example. The libraries can have gotchas, but that's a different thing altogether.
I haven't tossed my hat in the Rust or Go rings yet, but I'm watching to see if they do indeed exhibit advances which make them worth adopting. If so, then great.
That's my attitude. They show promise, but I've seen that too often in the past to hold my breath!