On Tuesday, 7 March 2017 at 18:45:55 UTC, Rico Decho wrote:
D seems to be in a situation where those who don't care have a
crap GC which needs to be improved and those who do care have
the tools to deal with it. So there needs to be ongoing
replacement of the D GC until there is something good, this is
a technical problem. That people who care about the effect of
GC still think D is a crap GC-based language implies there is
a marketing problem, not a technical one.
But I don't think that D's GC is fine for people who care about
it.
You'd have to be a lot more specific on what exactly you care
about, since GC always deals with tradeoffs.
If it is, why are people on this forum giving advices on how to
disable and/or avoid it for soft real-time applications where a
GC freeze can't be tolerated.
Because there are applications where the tradeoffs chosen for D's
GC can't be tolerated.
D's GC isn't a crap at all, but better designs and
implementations exist, and Nim's GC is one of them.
Better implementations of the same design, probably, but I
haven't checked. As far as I've been able to discern on a quick
look, Nim's current GC is also a mark-and-sweep GC, with the same
tradeoffs as D's GC, i.e. if you can't accept D's GC in an
application, you cannot accept Nim's.
Better designs? That, again, depends on what tradeoffs you're
willing to make.
For the goal "we want throughput on-par with C" I'm not aware of
better designs.
We can either learn from it, or ignore it... But the second
solution won't make D more appropriate for soft real-time
scenarios...
You'll have to be very explicit in what you think we should learn.
And D is perfectly viable for real-time scenarios: Don't call the
GC.
