A betterC base

[Jonathan M Davis]

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