The "no gc" crowd

[Jonathan M Davis]

On Tuesday, October 08, 2013 18:29:36 ponce wrote:
> On Tuesday, 8 October 2013 at 16:22:25 UTC, Dicebot wrote:
> > It is not overblown. It is simply "@nogc" which is lacking but
> > absolutely mandatory. Amount of hidden language allocations
> > makes manually cleaning code of those via runtime asserts
> > completely unreasonable for real project.
> 
> Hidden language allocations:
> - concatenation operator ~
> - homogeneous arguments void (T[]... args)
> - "real" closures that escapes
> - array literals
> - some phobos calls
> 
> What else am I missing?
> I don't see the big problem, and a small fraction of projects
> will require a complete ban on GC allocation, right?

I think that it's clear that for some projects, it's critical to minimize the 
GC, and I think that it's clear that we need to do a better job of supporting 
the folks who want to minimize GC usage, but I also think that for the vast 
majority of cases, complaints about the GC are way overblown. It becomes an 
issue when you're doing a lot of heap allocations, but it's frequently easy to 
design D code so that heap allocations are relatively rare such that they 
aren't going to be a serious problem outside of code which is performance 
critical to the point that it would be worrying about the cost of malloc 
(which most code isn't). Personally, the only time that I've run into issues 
with the GC is when trying to do use RedBlackTree with a lot of items. That 
has a tendancy to tank performance.

So, yes, it's problem. Yes, we need to improve the situaton. But for most 
situations, I think that the concern about the GC is way overblown.

- Jonathan M Davis