Andrei's list of barriers to D adoption

[H. S. Teoh via Digitalmars-d]

On Tue, Jun 07, 2016 at 07:24:55PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> 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).

I'm pretty sure there are applications for which GC is verboten, such as
high-performance game engines and what-not (but even for them, it's just
the core code that needs to avoid GC; peripheral things like in-game
scripting may actually be using a forced-GC scripting language -- it's
just that you want to control certain core operations to be maximally
performant).  But these are the exceptions rather than the norm.


[...]
> 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.

Actually, I'm not sure how much of Phobos actually depends on the GC.
Most of the stuff I use frequently are from std.range and std.algorithm,
and we've pretty much gotten rid of GC-dependence from most of the stuff
there.  Phobos modules that are GC-heavy ought to be avoided in
high-performance code anyway; the only problematic case I can think of
being std.string which greedily allocates. But we've been making
progress on that over the past year or so by turning many of the
functions into range-based algorithms rather than string-specific.

Lately I've been considering in my own code that a lot of things
actually don't *need* the GC. Even things like string transformations
generally don't need to allocate if they are structured to be a
range-based pipeline, and the consumer (sink) processes the data as it
becomes available instead of storing everything in intermediate buffers.
Even if you do need to allocate some intermediate buffers these are
generally well-scoped, and can be taken care of with malloc/free and
scope(exit).  The only time you really need the GC is when passing
around large recursive data structures with long lifetimes, like trees
and graphs.


> 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.

As Walter has said before: people who aren't already using the language
are probably only using GC as an excuse to not use the language. They
won't necessarily start using the language after we've bent over
backwards to get rid of the GC. We should be paying attention to current
users (and yes I know Manu has been clamoring for @nogc and he's a
current user).


> 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.
[...]

IMO a lot of Phobos modules actually could become much higher-quality if
rewritten to be GC-independent.  Some of the less-frequently used
modules are GC-heavy not out of necessity but because of sloppy code
quality, or because they were written prior to major D2 breakthroughs
like ranges and templates / CT introspection.


T

-- 
The early bird gets the worm. Moral: ewww...