Why many programmers don't like GC?

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Tue Jan 19 14:45:14 UTC 2021


On Tuesday, 19 January 2021 at 13:41:33 UTC, ddcovery wrote:
> That you want GC to work efficiently seems great to me... but 
> at least we agree that D memory management is (and must be) GC 
> based (so I really don't understand your somewhat over-acted 
> answer... maybe I need to read all the threads to understand 
> your discomfort. In any case, accept my forgiveness if I have 
> been able to bother you).

I think we need to understand the landscape around us. What was 
possible development directions for D 2-5 years ago are now less 
viable, because it is now a game of (forever) catching up to the 
other ones (C++/Rust) rather than being something different. 5 
years ago I would argued more for competing with C++/Rust 
head-to-head. I think that train has left the station. D is on a 
different track now.

So the possible viable directions has shrunk to improving the GC 
(by some minor language adjustments), switching to ARC or some 
other paradigm that give roughly the same programming experience 
as D users are accustomed to.


> Regarding the experience, do we really have to go into that? In 
> this forum there are more or less many people with university 
> level and between 10 and 30 years of experience ...

Yes, but would most of those have chosen D over Rust, Zig, Nim, 
C++20 today? We cannot know for sure, but there is clearly a 
significant uptake for competing languages that did not exist 10 
years ago.

So the "recruiting pool" is shrinking, that means losses (people 
leaving) cost even more today than 10 years ago...

So yes, we should absolutely listen to concerns from experienced 
developers with Comp.Sci. background if they chose to share them 
here in the forums. Tooling is a much bigger issue, but 
language/runtime adjustments are possible if we are willing to 
take some inconvenience in transition (some breakage).


> In my case, for example, I have not worked manually with memory 
> for decades (the 90s are a long way off, and my years with

Yes, I don't think most people want to work manually with memory, 
which is why mix-and-match is not sitting well. People who really 
want to do fully manual stick to C (they don't even want C++, 
right?).

Anyway, the more cores CPUs get, the more unacceptable blocking 
threads gets.

But I also suspect thread-pooling will eventually become the only 
reasonable option as one has to support CPUs with 2-30 cores... 
difficult to do that with a threading model. So, there are 
many... issues. Maybe threading is not the best model... Not sure.





More information about the Digitalmars-d-learn mailing list