Andrei's list of barriers to D adoption

Jonathan M Davis via Digitalmars-d digitalmars-d at puremagic.com
Tue Jun 7 19:24:55 PDT 2016


On Tuesday, June 07, 2016 19:04:06 H. S. Teoh via Digitalmars-d wrote:
> I think far too much energy has been spent arguing for a GC-less
> language than actually writing the code that would fix its associated
> performance issues, and my suspicion is that this is mostly caused by
> your typical C/C++ programmer mindset (of which I used to be a part)
> that's always obsessed about memory management, rather than any factual
> basis.

One of the other big issues is that many of the companies which use D and
have been active in the community have been doing _very_ high performance
stuff where they can't afford the GC to kick in even occasionally for less
than a hundred milliseconds (e.g. IIRC, Manu considering 10ms to be too long
for what they were doing at Rememdy). When you start getting requirements
that are that stringent, you start needing to not use the GC. And when some
of the more visible users of D have requirements like that and raise issues
about how the GC gets in their way, then it becomes a big deal even if it's
not a problem for your average D user.

We need to support GC-less code, and we need to avoid using the GC in Phobos
stuff where it's not necessary, since it will impede the high performance
folks otherwise.  And doing some of the stuff like turning off the GC in
specific code like you discussed will take care of many of the folks that
would be affected by GC issues. But for your average D program, I really
think that it's a non-issue, and as the GC situation improves, it will be
even less of an issue.

So, to some extent, I agree that there's too much an issue made over the GC
- especially by folks who aren't even using the language and pretty much
just react negatively to the idea of the GC. But we do still need to do a
better job of not requiring the GC when it's not actually needed as well as
better supporting some of the GC-less paradigms like ref-counting.

- Jonathan M Davis



More information about the Digitalmars-d mailing list