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/

On 6/16/17 6:51 AM, 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/ 

Great article! And thanks for sacrificing that Netflix time :)

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/

Nicely written.  I never bothered to look into this GC fine-tuning, as I don't need that level of optimization, but I finally have some idea of how this works.

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.

On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov [ZombineDev] wrote:

> 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.

Thanks! I agree that we need a range of posts on the GC. That's the whole point of the series. I have a set of posts I can write on topics within my current realm of knowledge, or that I can beef up on when the time comes, but beyond that I'm not the right guy to author some of the posts that need to be written. I haven't familiarized myself with all the corners, nor have I written any code that required me to push the boundaries or explore the possibilities.

A while back, I posted an announcement here explaining my goals with the GC series and asking for contributors. Aside from Atila's automem post, I haven't gotten any takers yet. I can, if need be, eventually write many of the posts I'd like to have, but that requires making time to familiarize myself with the topics. Such posts will also compete with those I plan to write on other topics.

So, in the interest of saving me a bit of time, I invite you and anyone who's willing to share their experiences and expertise with the GC. I'll happily publish any post that demonstrates allocation strategies, lifetime management, optimizations, or just generally helps to clear up misconceptions.

On Saturday, 17 June 2017 at 08:51:04 UTC, Mike Parker wrote:
> On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov [ZombineDev] wrote:
>
>> 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.
>
> Thanks! I agree that we need a range of posts on the GC. That's the whole point of the series. I have a set of posts I can write on topics within my current realm of knowledge, or that I can beef up on when the time comes, but beyond that I'm not the right guy to author some of the posts that need to be written. I haven't familiarized myself with all the corners, nor have I written any code that required me to push the boundaries or explore the possibilities.
>
> A while back, I posted an announcement here explaining my goals with the GC series and asking for contributors. Aside from Atila's automem post, I haven't gotten any takers yet. I can, if need be, eventually write many of the posts I'd like to have, but that requires making time to familiarize myself with the topics. Such posts will also compete with those I plan to write on other topics.
>
> So, in the interest of saving me a bit of time, I invite you and anyone who's willing to share their experiences and expertise with the GC. I'll happily publish any post that demonstrates allocation strategies, lifetime management, optimizations, or just generally helps to clear up misconceptions.

Hm. In my personal projects I'm using D exclusively as a high-level C, so without the GC. I have also Unique and RefCounted, that are very new and not so well tested. On the other hand I've written a good set of containers, that are completely @nogc and are different from std and EMSI containers. I would be interested to write a few lines about container usage, why not built-in arrays and so on. But I should say I need some time, I have currently enough to write at the semester's end :)

On Saturday, 17 June 2017 at 07:03:53 UTC, Petar Kirov [ZombineDev] wrote:
> 2. However, there's this long list of things that you have to avoid.

There's like 10 things to avoid in the language itself: http://dlang.org/spec/garbage.html#op_involving_gc

and most of them are obviously array stuff so it is easy to remember - and easy to skip with a simple array helper... which is often a useful optimization too, make one that uses stack space! You can write one in about 15 minutes.


Now, @nogc is a bit more restrictive since it isn't just avoiding GC calls.... it avoids the *possibility* of GC calls. Even if it would only actually run one in a million times at which point you want the program to die anyway.... @nogc still bans it. Even if it would never actually run, but some leaf function somewhere wrote `int getLength() { return _length; }` instead of `int getLength() @nogc pure const @safe nothrow { return _length; }`... it obviously doesn't run the gc, but still fails @nogc for its entire call tree.


This is why I consider @nogc to be an *extremely* niche feature and generally harmful. It makes things look a lot harder than it really is - people confuse `@nogc` with "no gc". Instead, I suggest just minding the list and using runtime profiling and debugging to ensure your needs are met in actual practice.

> 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*).

of course you could always `printf` lol.

The reason writeln fails @nogc is that it *might* throw an exception with most args if stdout is closed or something.

Perfect example of an *extremely* rare case failing @nogc's ridiculously strict requirements.

On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:
>
> This is why I consider @nogc to be an *extremely* niche feature and generally harmful. It makes things look a lot harder than it really is - people confuse `@nogc` with "no gc". Instead, I suggest just minding the list and using runtime profiling and debugging to ensure your needs are met in actual practice.
>

As a counterpoint: It's true that it's a bit niche, but when you have "no gc" then @nogc really helps with peace of mind (only one allocation and you may crash).

Guillaume Piolat wrote:

> On Saturday, 17 June 2017 at 13:05:50 UTC, Adam D. Ruppe wrote:
>>
>> This is why I consider @nogc to be an *extremely* niche feature and generally harmful. It makes things look a lot harder than it really is - people confuse `@nogc` with "no gc". Instead, I suggest just minding the list and using runtime profiling and debugging to ensure your needs are met in actual practice.
>>
>
> As a counterpoint: It's true that it's a bit niche, but when you have "no gc" then @nogc really helps with peace of mind (only one allocation and you may crash).

yeah, it helps a little... in (let's be honest) rare situations where you really want to be *completely* free of any possible gc allocation. in most real-life scenarios you're ok with "mostly gc-free, except for exceptional cases" (like writeln, for example), and you have no way to express it. i end up not using @nogc at all (except on simple `return a` getters), despite the fact that many of my code rarely allocates.

there should be a way to say "i don't want gc on this code path, but it is ok for this one" (like throwing), without resorting to dirty tricks with casting and lambdas. something like `@raregc` ;-).

but then, how we should define "rare"? that attribute will quickly become useless, as people will mark arbitrary code with it.

so, `@nogc` is mostly useless IRL (you can't even `enforce` with it), and `@raregc` will become useless if introduced. and the sole reason (as i see it) of introducing `@nogc` was to please people complaining about gc allocations, no matter how often they're done, and on which code path. i myself see it as "PR design", which attracts people only to make them find that using D with `@nogc` is a PITA, due to `@nogc` being too restrictive.

what `@nogc` *really* does now is dividing codebases into "i will do all kind of dirty tricks to avoid GC at all costs, even if it is not really necessary", and into "ah, screw it, i don't care". to me, it looks like `@nogc` does more bad than good now.

Am Fri, 16 Jun 2017 13:51:18 +0000
schrieb Mike Parker <aldacron@gmail.com>:

> 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/
> 
> 

Nice blog post!

> Let’s imagine a hypothetical programmer named J.P. who, for reasons he considers valid, has decided he would like to avoid garbage collection completely in his D program. He has two immediate options.

I think I might know that hypothetical programmer ;-)

-- Johannes