It would be most unfortunate if GC-ridden languages came to predominate. It is practically impossible for an OS memory manager to "handle" GC well, just as it is practically impossible for the program itself to do so. It is in the nature of GC to interact badly with caches, and we are ever more dependent on an increasing variety of caches.
Every time the above is pointed out, somebody pops up and says that some new or old wrinkle has potential to mitigate the problems. Invariably there's a paper with lots of artificial benchmarks, running on a machine dedicated to nothing but running those benchmarks. Invariably such programs interact badly with real programs on real machines.
Besides its fundamental problems, GC never advances much because it can't be encapsulated. For every place that needs it, it must be re-done from scratch. The cunning tricks of the last implementation don't work in the next.
Academia can't see limitations of GC because the ideal academic program only ever manages memory. Real-world programs must manage other much more limited resources -- network sockets, database connections, disks -- and any method sufficient to manage them suffices for memory as well. No current language threatens C++ for serious programming, however useful such a language would be. In large part this is because any such rival would first need to impress academics who, for the most part, have no clue about what makes a language actually useful.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds