On Friday, 16 June 2017 at 13:51:18 UTC, Mike Parker wrote:
I've been meaning to get this done for weeks but have had a
severe case of writer's block. The fact that I had no other
posts ready to go this week and no time to write anything at
all motivated me to make time for it and get it done anyway. My
wife didn't complain when I told her I had to abandon our
regular bedtime Netflix time block (though she did extract a
concession that I have no vote in the next series we watch).
Thanks to Vladimir, Guillaume, and Steve, for their great
feedback on such short notice. Their assistance kept the blog
from going quiet this week.
The blog:
https://dlang.org/blog/2017/06/16/life-in-the-fast-lane/
Reddit:
https://www.reddit.com/r/programming/comments/6hmlfq/life_in_the_fast_lane_using_d_without_the_gc/
Thanks for the nice write-up, Mike! Posts like this one really
help clear many misconceptions about the language. Keep them
coming!
I think the next blog should address what's possible without the
GC and what features of the language/library make it more
productive than languages like C and C++ even in @nogc code. I'm
getting the impression that people on Reddit (and in general
people inexperienced with language) see this:
1. Yes, it's *technically* possible to use D without the GC.
2. However, there's this long list of things that you have to
avoid.
3. So while this "@nogc" is technically possible you loose so
much of the language that you're better of with C++ (where e.g.
"cout" just works*).
* For some unspecified meaning of working.
And also comments like:
Reading this article makes me realize how naturally C++
(particularly C++11) does without a GC. It's the right tool for
the job if your program must not have a GC.
Which obviously can't be further from the truth. That's why we
need a systematic answer to how to use D effectively without the
GC.
The right answer is three fold:
A) Examples of idiomatic D code - generic functions agnostic
about the memory management strategy like range algorithms;
B) Having solid tools at the language-level for implementing
correct and relatively easy-to-use library primitives like smart
pointers and containers - @safe + pure + scope.
C) Maintaining a list of functions/modules/third-party libraries
that are usable in @nogc land.
But most of all, the focus should be on productivity and
ease-of-use, because otherwise people tend to get the impression:
TL;DR this is too complicated for me -> I can't use D without the
GC -> Using D without the GC is not feasible.
