Life in the Fast Lane (@nogc blog post)

[via Digitalmars-d-announce]

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.