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.

Reply via email to