On Friday, 6 October 2017 at 17:27:03 UTC, H. S. Teoh wrote:
Why is GC a problem?
T
--
**** Everybody talks about it, but nobody does anything about
it! -- Mark Twain**
Are you sure your quotes are randomly generated ??
Jonathan Davis wrote:
"We don't want D's standard library to rely on the GC when it
doesn't need to, but there are language features that require it
and really couldn't work with it, and there are cases where it's
going to be involved by default for @safety reasons."
Perception is so important when people are making decisions about
something they don't know. (As Walter says, you have to write
tens of sloc in a language to really see it's benefits. They
won't be so evident if you write D like the languages you know).
So I think the GC series has been very helpful.
But it might also be helpful to be very explicit on the functions
that can and can't be called with nogc (I mean a top level
overview in the docs) because it's one of the remaining sources
of FUD that people say "yeah but you can't use large parts of the
standard library without the GC".
And for things that are useful and easiest done with GC it would
be nice to have an alternative that doesn't depend on the GC - if
for no other reason than to address objections. So the answer is
then "yes - you're right, these X functions depend on the GC, but
there are similar ones that don't". (Walter already started that
for functions that use the GC for purely legacy reasons but I
mean for more difficult cases too. I know Weka wrote their own
versions of some std.algorithm functions for example). Many
things aren't much work, but when you have a lot to do, even
small frictions can have big consequences.
So it's also a documentation question - it's not that easy from
the outside last time I looked to see just how easy
std.experimental.allocator is to use.
