On Wednesday, 16 April 2014 at 22:42:23 UTC, Adam Wilson wrote:

Long story short, Tracing vs. Ref-counting are algorithmic duals and therefore do not significantly differ. My read of the article is that all the different GC styles are doing is pushing the cost somewhere else.

All memory management schemes cost, even manual memory management. IMO that's not the point. The point is that each memory management scheme distributes the cost differently. One distribution may be more suitable for a certain problem domain than another.

ARC may in fact be the most advantageous for a specific use case, but that in no way means that all use cases will see a performance improvement, and in all likelihood, may see a decrease in performance.

The same can be said about stop-the-world mark-and-sweep. It is also specialized to a specific problem domain. As an example, it doesn't scale well to the real-time/embedded domain.

That makes ARC a specialization for a certain type of programming, which would then remove D the "Systems" category and place it in a "Specialist" category. One could argue that due to the currently non-optional status of the GC that D is currently a "Specialist" language, and I would be hard pressed to argue against that.

D is currently in the "Specialist" category. It is already specialized/biased to PC/Server applications. C/C++ are the only languages I know of that scale reasonably well to all systems. I think D has the potential to change that, but it will require, first, recognition that D is not yet a "Systems" language like C/C++ are, and second, the will to change it.

@nogc removes the shackles of the GC from the language and thus brings it closer to the definition of "Systems". @nogc allows programmers to revert to C-style resource management without enforcing a specialized RM system, be it GC or ARC. @nogc might not make you run through the fields singing D's praises, but it is entirely consistent with the goals and direction of D.

@nogc doesn't allow users to revert to C-style resource management because they don't have control over implicit allocations in druntime and elsewhere. It just disables them. Users still have to build alternatives. There's no escaping the cost of memory management, but one could choose how to distribute the cost.

Mike

Reply via email to