Why many programmers don't like GC?

[Ola Fosheim Grøstad]

On Monday, 18 January 2021 at 12:17:24 UTC, aberba wrote:
> If you read the Origin of D book, you would see that the GC was 
> a desire thing when D was designed probably due to how useful 
> it is for ... as said, 90% or so of software development. So at 
> this point, fighting the GC isn't (in my opinion) the right 
> strategy.

Not fighting the GC, but the whole argument about improving it, 
or mix or match, does not work for most developers looking for a 
new language. So either there has to be something else or the 
language semantics will have to be adjusted to get a better GC. 
That is the crux, the GC cannot be significantly improved without 
some minor adjustment to the language (with some breaking 
changes).

To get there the majority have to be in favour of it. If 50% of 
the D community pulls strongly in the opposite direction, then 
the GC cannot improve in a meaningful way.

Yes, it is natural that the current D population don't mind the 
current GC. Otherwise they would be gone... but then you have to 
factor in all the people that go through the revolving door and 
does not stay. If they stayed the eco system would be better. So 
the fact that they don't... is effecting everyone in a negative 
way (also those that har happy with the runtime).


> I should also say that I notice your point about improving GC 
> in D and making it more optional as much as possible for things 
> that still rely on GC...ARC, etc. 👍

ARC is a pretty big change, so it will depend on library authors 
supporting it. It also requires a new intermediate 
representation. So I don't think it will happen. Thread local GC 
seems most reasonable. As CPUs get more and more threads it 
becomes more and more unacceptable to lock all threads during 
collection.

> The OP was about why programmers don't "like" GC.

Programmers like GC, just not for system level programming. C++ 
has had the Boehm GC since the mid 90s. Only a tiny percentage 
use it. Forget about game engines, many games have game contents 
written in Lua and other scripting languages and can live with 
incremental GC with very little impact on interaction (you could 
use Javascript too). The game engine itself is usually not 
relying on GC, just the game content part.


> I've been here long enough to see the GC being one of the most 
> re-occurring issues for discussion (probably due to new users 
> coming in).

Yes, they come in, but do they stay? If they don't stay, then our 
eco system suffers from it.

D would be in a better position by tracking why people leave and 
then fix those concerns (if they are related to the 
language/runtime).

> There's been official posts about how D's style of GC isn't 
> like that of fully managed languages, how to write nogc code in 
> D, how to minimize GC, among others.

Yes, but people who are well versed in system level programming 
know how to to this already, they just want more hassle than they 
get in other languages. And those are also the same people that 
would write solid libraries/improve on the compiler. So not being 
able to retain those developers is a biiiiig loss.


> Now if none of these work for you (for some special reason), 
> then the long-term strategy might be an alternative runtime and 
> or std. Which isn't a good answer that thought was worth 
> it...so I didn't include that.

Actually that is a good answer, if it comes with the appropriate 
language changes, like tagged unions and banning conflicting 
pointers in unions.

What works for me, is not the issue, but what IS the direction?? 
Where are we going? That is the real issue.

I am perfectly ok with C++20 for low level programming. I don't 
need D for that. It is totally OK if the D community decides to 
make it more high level and easier to deal with for newbies who 
come from Python.


> If none of these work, then I (as in my personal opinion), 
> don't know what else is available.

I am ok with any one of these alternatives:

Alternative 1: Adjust the language semantics so that the GC can 
be improved and accept some breaking changes.

Alternative 2: Switch focus from being a system level language to 
becoming more of a high level language.

Alternative 3: Implement ARC.

The other alternatives don't really work. Doing what Rust does is 
now 2 years late, it would take 5 years to get there. Doing what 
C++ does, does not help. Why would I use D instead of C++ then?

Just pick a direction, because right now, the direction is not 
very clear and then progress becomes impossible. No direction, 
means no progress...