Getting completely (I mean ENTIRELY) rid off GC

[deadalnix via Digitalmars-d]

On Thursday, 11 September 2014 at 12:38:54 UTC, Andrey Lifanov
wrote:
> Hello everyone! Being a C/C++ programmer I don't understand, 
> why such language as D (system programming language) 
> implemented garbage collector as a core feature, not as 
> additional optional module or library. I and many other C/C++ 
> programmers prefer to control things manually and use flexible 
> allocation schemes that suitable for concrete situations. When 
> every nanosecond matters, this is the only option, at least 
> nowadays.
>
> So this particular thing stops many of us from using D. When 
> you can abandon performance, you usually choose Java (Scala) or 
> C# because of their rich support and libraries. And the 
> opposite matter is when you need high performance. In this case 
> there is almost nothing to choose from. C/C++11 now looks not 
> so bad.
>
> And I think of idea of complete extraction of GC from D. For 
> this to achieve, I suppose, I have to dig deeply into D 
> compiler and also correct/re-implement many things in modules, 
> so this ends up with almost new version of D.
>
> I would like to hear your suggestions and some basic 
> instructions. Maybe this is not a good idea at all or it will 
> be very hard to realize.
>
> Thank you for your attention!

Dear C++ programmer. I know you language do not give a damn about
multicore, but it is a reality in the hardware for more than 10
years now.

As it turns out, outside being a convenience, a GC is capital for
multicore programming. Here are some of the reason:
   - Other memory management technique require bookkeeping. In a
multicore environment, that mean expensive synchronization.
   - It allow, combined with immutability, to get rid of the
concept of ownership. That mean data sharing without any sort of
synchronization once again. This is useful for multicore, but
even on a single core, D's immutable strings + slicing have
proven to be a killer feature for anything that is text
processing like.
   - This is an enabler for lock free data structures. As you don't
need to do memory management manually, your datastructure can
remain valid even with less operation, which generally makes it
easier to make those atomic/lock free.

It has other various benefits:
   - It removes a whole class of bugs (and memory corruption bug
tend to be not the easiest to debug).
   - It remove constraint from the original design. That mean you
can get a prototype working faster, and reduce time to market.
This is key for many companies. Obviously, it still mean that
you'll have to do memory management work if you want to make your
code fast and efficient, but this is now something you can
iterate on while you have a product working.

Now that do not mean GC is the alpha and omega of memory
management, but, as seen, it has great value. Right now, the
implementation is now super good, and it has been made a priority
recently. We also recognize that other technique have value, and
that is why the standard lib propose tool to do reference
counting (and it can do it better than C++ has it knows if
synchronization is necessary). There is important work done to
reduce memory allocation were it is not needed in the standard
lib, and @nogc will allow you to make sure some part of your code
do not rely on the GC.