On Wed, Jan 12, 2022 at 11:14:54AM -0500, Steven Schveighoffer via Digitalmars-d-announce wrote: [...]
> Look at Sociomantic -- they still used the GC, just made sure to minimize the possibility of collections.
> 
> I wonder if there is just so much fear of the GC vs people who actually tried to use the GC and it failed to suit their needs. I've never been afraid of the GC in my projects, and it hasn't hurt me at all.
[...]

Like I said, my suspicion is that it's more of a knee-jerk reaction to the word "GC" than anything actually founded in reality, like somebody actually wrote a game in D and discovered the GC is a problem vs somebody is *thinking* about writing a game in D, then thinks about the GC, then balks because of the expectation that the GC is going to do something bad like kill the hypothetical framerate or make the not-yet-implemented animation jerky.

Those who actually wrote code and found GC performance problems would have just slapped @nogc on their code or inserted GC.disable at the beginning of the game loop and called it a day, instead of getting all knotted up in the forums about why GC is bad in principle.


T

-- 
I'm still trying to find a pun for "punishment"...

On Wednesday, 12 January 2022 at 16:17:02 UTC, H. S. Teoh wrote:
> Depends on what kind of games, I guess. If you're writing a 60fps real-time raytraced 3D FPS running at 2048x1152 resolution, then *perhaps* you might not want a GC killing your framerate every so often.

Resolution is down to GPU performance, raytracing ditto.  Realtime GC is a thing (not for d, of course); consistently sub-millisecond pause times are achievable.  Given 16ms frametimes (you mention 60fps), that seems reasonable.


> (But even then, there's always GC.disable and @nogc... so it's not as if you *can't* do it in D. It's more a psychological barrier triggered by the word "GC" than anything else, IMNSHO.)

Agree.

On Wed, Jan 12, 2022 at 05:42:46PM +0000, bachmeier via Digitalmars-d-announce wrote:
> On Wednesday, 12 January 2022 at 16:52:02 UTC, Arjan wrote:
[...]
> > I think it stems from experience from long ago when JAVA was HOT and sold as the solution of all world problems, but failed to meet expectations and was dismissed because they found is was the GC what made it fail..

That was my perception of GC too, colored by the bad experiences of Java from the 90's.  Ironically, Java's GC has since improved to be one of the top world-class GC implementations, yet the opinions of those who turned away from Java in the 90's have not caught up with today's reality.


[...]
> I don't think they're necessarily wrong. If you don't want to deal with GC pauses, it may well be easier to use an approach that doesn't have them, in spite of what you have to give up. On the other hand, many of them have no idea what they're talking about. Like claims that a GC gets in your way if the language has one.

Depends on the language; some may indeed require GC use to write anything meaningful at all, and some may have the GC running in the background.  However, D's GC only ever triggers on allocations, and as of a few releases ago, it doesn't even initialize itself until the first allocation, meaning that it doesn't even use up *any* resources if you don't actually use it (except for increasing executable size, if you want to nitpick on that).  This must be one of the most non-intrusive GC implementations I've ever seen.  Which makes me *really* incredulous when the naysayers complain about it.


T

-- 
There are two ways to write error-free programs; only the third one works.

On 1/12/2022 8:14 AM, Steven Schveighoffer wrote:
> I wonder if there is just so much fear of the GC vs people who actually tried to use the GC and it failed to suit their needs. I've never been afraid of the GC in my projects, and it hasn't hurt me at all.

My experience with people who don't want to use a product I've worked on is:

1. they'll give reason X, which is usually something that sounds convenient
2. I fix X, they can use it now!
3. they then give reason Y, after thinking about it for a minute

What's happening is neither X nor Y is the real reason. They just don't want to tell me the real reason, usually because it's an emotional one.


The GC issue fits all of that.

For example, back in the olden days (the 1980s), as related to me by a friend:

X: The most important thing I want in a C++ compiler is speed! I cannot emphasize enough how important that is!
Y: No, that isn't the reason. The most important thing to you in a C++ compiler is brand name.
X: (Dumbfounded) Why would you say that?
Y: Because you are using Microsoft C++, which is 4 times slower than Zortech C++.
X: Oh.


Another one:

Friend: You should write a native Java compiler! It'll take over the world! I really want a native Java compiler!
Me: I already wrote one, Symantec's Java compiler. You can get it and use it today!
Friend: Oh. [Changes the subject]


Now, consider BetterC, a 90% subset of D, and no GC in sight. It changed nobody's mind who didn't use D "because of the GC", because that is not the real reason.

On Wednesday, 12 January 2022 at 16:14:54 UTC, Steven Schveighoffer wrote:
>
>
> I wonder if there is just so much fear of the GC vs people who actually tried to use the GC and it failed to suit their needs. I've never been afraid of the GC in my projects, and it hasn't hurt me at all.
>
> -Steve

No. Fear is irrelevant.

Fear of GC is just a catch-all-phrase that serves no real purpose, and provides no real insight into what programmers are thinking.

It's all about autonomy and self-government (on the decision of whether to use GC or not, or when to use it, and when not to use it.

Programmers want the right of self-government, over their code.

This is not politics. It's human psychology.

It is, to a large extent I believe, what attracts people to D.

I don't believe people are attracted to D because it has GC. There are better languages, and better supported languages, with GC.

D should not spend time promoting 'GC', but rather promote how programmers can have this autonomy.

Also, the idea that 'GC' means you never have to think about memory management... is just a ridiculous statement..

..Every programmer *should* be thinking about memory management.

On Wednesday, 12 January 2022 at 20:41:56 UTC, Walter Bright wrote:
>
> My experience with people who don't want to use a product I've worked on is:
>
> 1. they'll give reason X, which is usually something that sounds convenient
> 2. I fix X, they can use it now!
> 3. they then give reason Y, after thinking about it for a minute
>
> What's happening is neither X nor Y is the real reason. They just don't want to tell me the real reason, usually because it's an emotional one.

Yes, emotions come into play, but the 'emotion argument' on its own explains nothing.

The 'real reason' is that people are by nature, aversive to losses.

This impacts how people evaluate a choice.

e.g. an aversion to losing an existing skill set...

what you need to do, is argue you're case in a way that produces more dopamine neurons to activate ;-)

https://en.wikipedia.org/wiki/Loss_aversion