On Tuesday, 4 February 2014 at 03:43:53 UTC, ed wrote:
On Tuesday, 4 February 2014 at 01:36:09 UTC, Adam Wilson wrote:
On Mon, 03 Feb 2014 17:04:08 -0800, Manu <turkey...@gmail.com>
wrote:
On 4 February 2014 06:21, Adam Wilson <flybo...@gmail.com>
wrote:
On Mon, 03 Feb 2014 12:02:29 -0800, Andrei Alexandrescu <
seewebsiteforem...@erdani.org> wrote:
On 2/3/14, 6:57 AM, Frank Bauer wrote:
Anyone asking for the addition of ARC or owning pointers
to D, gets
pretty much ignored. The topic is "Smart pointers instead
of GC?",
remember? People here seem to be more interested in
diverting to
nullable, scope and GC optimization. Telling, indeed.
I thought I made it clear that GC avoidance (which includes
considering
built-in reference counting) is a major focus of 2014.
Andrei
Andrei, I am sorry to report that anything other than
complete removal of
the GC and replacement with compiler generated ARC will be
unacceptable to
a certain, highly vocal, subset of D users. No arguments can
be made to
otherwise, regardless of validity. As far as they are
concerned the
discussion of ARC vs. GC is closed and decided. ARC is the
only path
forward to the bright and glorious future of D. ARC most
efficiently solves
all memory management problems ever encountered.
Peer-Reviewed Research and
the Scientific Method be damned! ALL HAIL ARC!
Most of us know and understand the issues with ARC and that
with a GC. Many of us have seen how they play out in systems
level development. There is a good reason all serious driver
and embedded development is done in C/C++.
A language is the compiler+std as one unit. If Phobos depends
on the GC, D depends on the GC. If Phobos isn't systems level
ready, D isn't systems level ready. I've heard arguments here
that you can turn off the GC, but that equates to rewriting
functions that already exists in Phobos and not using any
third-party library.
At Sociomantic, that is exactly what we have done. Phobos is
almost completely unusable at the present time.
I personally don't think that ARC would make much difference. The
problem is that *far* too much garbage is being created. And it's
completely unnecessary in most cases.
To take an extreme example, even a pauseless, perfect GC,
wouldn't make std.json acceptable.
Why would anyone seriously consider that as an option? Embedded
C++ has std:: and third-party libraries where memory is under
control?
Realistically D as a systems language isn't even at the hobby
stage.
We're using D as a systems language on a global commercial scale.
And no, we don't use malloc/free. We just don't use Phobos.
