It isn’t an “anti-GC crowd”, it is based in pretty solid theoretical computer science with large amounts of empirical evidence behind it. GC-based environments are incompatible with schedule-based safety, optimization, etc which are major optimizations and design elements in modern systems.
No one has ever demonstrated a systems architecture that can outperform a state-of-the-art schedule-optimized design. This result is expected in theory. There are several optimality theorems, treated as a soft limit, that only hold true if you don’t control the schedule. The requirements of GCs guarantee you don’t control the schedule. State-of-the-art system designs, in non-GC environments, aren’t limited by those theorems and frankly run circles around GC-based systems. I work with a lot of companies that run nothing but managed languages and even they don’t believe that produces an optimal system, just an adequate one for non-intensive use cases. And that is a legitimate position.
You clearly are deeply invested in the superiority of GCs for all use cases. That’s fine. I make a lot of money replacing them with empirically much higher performance systems. There isn’t a lot of computer science to support the pro-GC position if performance is the objective. And to be clear, the loss of performance is integer factor, not something that can be trivially dismissed.
And I make money replacing C++ systems with ones written in AOT/JIT managed languages, with different kinds of automatic memory management.
The last time I did full stack C++ development was in 2006, nowadays its use is constrained to a couple of unavoidable native libraries, or GPGPU shaders.
Not everything can be proved in practice when management prefers to give money to the ones that sabotage projects like Windows Dev team has done to Longhorn and Midori efforts.
Are you aware that for quite some time any of your Bing searches using Asian servers were powered by Midori?
Thankfully this is a problem that eventually will get fixed by generational evolution, pity I won't be around to fully witness it.
I agree with you that a GCd language, almost by definition can’t be a low-level language.
I’m not familiar with schedule-optimized design though, could you expand a bit on it?
But I assume it can’t easily be used with routinely changing design requirements, with non-obvious object life-times, like most business applications, CRUD apps —- which is the primary use-case of high-level languages.
No one has ever demonstrated a systems architecture that can outperform a state-of-the-art schedule-optimized design. This result is expected in theory. There are several optimality theorems, treated as a soft limit, that only hold true if you don’t control the schedule. The requirements of GCs guarantee you don’t control the schedule. State-of-the-art system designs, in non-GC environments, aren’t limited by those theorems and frankly run circles around GC-based systems. I work with a lot of companies that run nothing but managed languages and even they don’t believe that produces an optimal system, just an adequate one for non-intensive use cases. And that is a legitimate position.
You clearly are deeply invested in the superiority of GCs for all use cases. That’s fine. I make a lot of money replacing them with empirically much higher performance systems. There isn’t a lot of computer science to support the pro-GC position if performance is the objective. And to be clear, the loss of performance is integer factor, not something that can be trivially dismissed.