Yeah, let's use a memory unsafe language, handle memory management by hand and just completely ignore the fact that no human being has ever managed to consistently write bullet-proof code in it.
Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?
I guess you also roll your own crypto and implement stuff in assembler “for performance”?
Sometimes you need performance or there are other constraints, in which case your choice of language is very limited.
Automated memory management works, but not all the time.
And how about other resources? How you make sure your mutex gets released? Add a comment "please don't forget to release this one"?
How about file handle, temporary file, serial port, DMA, GPU, network port and other limited resources?
BTW, I think most of the brightest minds you mention use C or C++ on daily basis. :)
"Automated memory management works, but not all the time."
[citation needed]
"BTW, I think most of the brightest minds you mention use C or C++ on daily basis"
I doubt it. Most of the brightest minds I have met, at least in academia, use high-level languages: Python, OCaml, Lisp, Haskell, etc. They have more important things to worry about than whether or not it is safe to deallocate objects.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses"
Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?
All the operating systems (Linux, Windows, Mac, iOS, Android), most of the desktop apps (Office, Photoshop), programming languages (PHP, Ruby, JavaScript, Python, both Sun and IBM JVMs), browsers (IE, Chrome, Firefox), web servers (Apache, nginx), database (Oracle, MS SQL, mySQL, Postgres, Redis, MongoDB), Google's search engine, eBay, Bing, Facebook, most of the games, embedded medical devices etc.
"Do you realize that almost everything widely used today is implemented in C, C++ or ObjectiveC?"
Yeah, and we are plagued by the bugs and security problems made possible by those languages. Imagine how much more we could be doing if programmers were not spending hours trying to figure out where a dangling pointer was created.
Really, the popularity of C, C++, and related languages has little to do with the languages themselves. C became popular because of Unix, not because of its technical features, and Unix became popular because of its licensing. C++ became popular because of Windows, not because of its technical features; Windows became popular because of the Unix Wars and because of MS Office. If Unix had been written in Lisp or ML, we would be talking about how popular Lisp or ML are. For what it's worth, entire operating systems were written in Lisp at one time; their failure had nothing to do with their technical merits and everything to do with terrible marketing and bad predictions.
If you want to talk about how fantastic C or C++ is, try pointing to an overwhelming success story that could not have happened without the language. Altran Praxis has the lowest bug rate in the industry; they credit the SPARK programming language, which is well-suited to the formal verification techniques they rely on. The military planning system DART paid both its own development costs and several decades of research that led up to it; it was thrown together in a few weeks using Lisp. I have yet to hear that kind of success story from C++ programmers; the only thing I ever seem to hear about are squeezing a few extra clock cycles out.
If this were a popularity contest, we would still be hand-rolling assembly language. The same reasons that led programmers to use compiled languages apply to switching away from low-level languages like C and C++. Sure, people are still writing assembly language, but it is a niche. That is where C and C++ should be: a niche, mostly just for maintaining legacy code that is too expensive to rewrite in a better language.
Using software which automates memory management, engineered by the brightest minds on this topic, is for hipsters, right?
I guess you also roll your own crypto and implement stuff in assembler “for performance”?