On Thursday, February 08, 2018 11:28:52 H. S. Teoh via Digitalmars-d wrote: > On Thu, Feb 08, 2018 at 12:17:06PM -0700, Jonathan M Davis via Digitalmars-d wrote: > > On Thursday, February 08, 2018 14:54:19 Adam D. Ruppe via Digitalmars-d > > > wrote: > [...] > > > > Garbage collection has proved to be a smashing success in the > > > industry, providing productivity and memory-safety to programmers of > > > all skill levels. D's GC implementation follows in the footsteps of > > > industry giants without compromising expert's ability to tweak even > > > further. > > > > > > > > > > > > That's what we should be saying every single time someone mentions > > > GC. Including it was the RIGHT DECISION and we should own that. > > > > +10000000000000000000 > > [...] > > /// ditto. :-P > > While I agree that we *should* make D as usable as possible for those > who don't want to use the GC, all too often that belies the benefits > that having a GC actually brings. It's true that the current GC could > be improved, and that we could reduce GC-dependence in Phobos, provide > better @nogc support, etc.. But we should not apologize for *having* a > GC, as if it was somehow a wrong decision. > > I think it's *great* to have a GC. It has saved me *so* much time, > energy, and frustration that would have been spent obsessing over memory > management every other line of code I write; now I can instead direct > that energy towards actually solving stuff in the problem domain that is > the entire purpose of the code in the first place. And for those times > when performance is an issue, GC.disable and GC.collect have proven > sufficient to clear the bottleneck in 95% of the cases. And besides, D > doesn't stop you from dropping back to malloc/free if you really need > to. Or, for that matter, RefCounted.
I am completely fine with making more features pay-as-you-go so long as it doesn't require me to change any existing code (e.g. I shouldn't have to import the GC - but if no code in your program invokes the GC and that results in the GC not being linked in, that's fine with me). But whenever I see folks trying to push -betterC as the way to go or push to get the GC out of Phobos, I start getting worried about that negatively affecting normal D code. I totally agree that there are times when you don't want something on the GC heap, and there are times when you need to do stuff like reference-counting (e.g. for OS-level resources that need to be released deterministically), but on the whole, having the GC is fantastic, and for most stuff, it works wonderfully. We should strive to minimize the cost of nice stuff like the GC so that it's as much pay-as-you-go as is reasonable, but at some point, if you're not careful, you start losing out on nice features in your attempt to appease the folks who think that they can't afford the GC in their enivornment (whether they actually can or not). And I would much rather see folks have to go to a bit of extra work to turn off something that most programs are going to benefit from than to make it harder for your average D program to take advantage of all of D's great features. - Jonathan M Davis
