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.


T

-- 
If you want to solve a problem, you need to address its root cause, not just its symptoms. Otherwise it's like treating cancer with Tylenol...

On 2/8/2018 10:11 AM, JN wrote:
> I agree, however these languages would probably have been successful even without GC, using e.g. some form of automatic reference counting.

If reference counting would work with Java, and was better, wouldn't the Java developers have done it decades ago?

On Thursday, 8 February 2018 at 19:34:20 UTC, Walter Bright wrote:
> On 2/8/2018 10:11 AM, JN wrote:
>> I agree, however these languages would probably have been successful even without GC, using e.g. some form of automatic reference counting.
>
> If reference counting would work with Java, and was better, wouldn't the Java developers have done it decades ago?

The developers working on .NET had the opportunity to learn from Java, yet they went with GC.[0] Anyone that says one approach is objectively better than the other is clearly not familiar with all the arguments - or more likely, believes their problem is the only real programming problem.

[0] https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-management/

On Thursday, 8 February 2018 at 19:51:05 UTC, bachmeier wrote:
> The developers working on .NET had the opportunity to learn from Java, yet they went with GC.[0] Anyone that says one approach is objectively better than the other is clearly not familiar with all the arguments - or more likely, believes their problem is the only real programming problem.

Reference counting isn't a general solution, and it is very slow when you allow flexible programming paradigms that generate lots of objects.

So, it all depends on how much flexibility you want to allow for your programmers and still having reasonable performance.

(The vast majority of high level programming languages use GC and has done so since the 60s.)

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

On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote:
> On 2/8/2018 9:03 AM, Dave Jones wrote:
>> If D had a decent garbage collector it might be a more convincing argument.
>
> 'Decent' GC systems rely on the compiler emitting "write gates" around every assignment to a pointer. These are justified in languages like Java and Go for which everything is GC allocated, but they would be a performance disaster for a hybrid language like D.
>
> More precise GC exacts heavy runtime penalties, too, which is why attempts to add them to D have had mixed results.
>
> I.e. it isn't an issue of us D guys being dumb about the GC.
>
>> If going malloc didnt lose you a bunch of features and bring a bunch of other stuff you need to be careful of, that might be a good argument too.
>
> With @nogc, you don't have to be careful about it. The compiler will let you know.

.NET, Eiffel, Modula-3 and the various Oberon variants are all examples where not everything is GC allocated.

C# 8.0 with .NET Native is getting the features I mostly cared from D.

On 2/8/2018 11:51 AM, bachmeier wrote:
> The developers working on .NET had the opportunity to learn from Java, yet they went with GC.[0] Anyone that says one approach is objectively better than the other is clearly not familiar with all the arguments - or more likely, believes their problem is the only real programming problem.
> 
> [0] https://blogs.msdn.microsoft.com/brada/2005/02/11/resource-management/

That really is an informative article, thanks. The only issue with it is that it doesn't cover the newer C++ ref counting model, which has proved popular.

On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:
> Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection.

Who cares? Even if the success isn't because of GC per se, the ubiquity of it in the real world means it certainly isn't a deal breaker.

On Thursday, 8 February 2018 at 16:40:46 UTC, John Gabriele wrote:
> Regarding what you said about the implementation of the GC following in the footsteps of industry giants, what specifically about D's GC impl is patterned after other industry giant's GC's?

The simple fact that it is a GC. These debates aren't about technical details. You don't see the reddit detractors actually arguing implementation details - they just equate GC with bad.

But GC isn't bad. GC is used by virtually everyone, to big productivity and memory safety gains by most, and evidently, without seriously getting in the way by the majority of the remainder.... just like how D's specialized users who can't afford GC still manage to use D.

On Thursday, 8 February 2018 at 23:27:25 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:
>> Citation needed on how garbage collection has been a smashing success based on its merits rather than the merits of the languages that use garbage collection.
>
> Who cares? Even if the success isn't because of GC per se, the ubiquity of it in the real world means it certainly isn't a deal breaker.

But D, unlike many other languages, promotes itself as primarily a system programming language

https://en.wikipedia.org/wiki/System_programming_language

So I would say yes, D's success does depend in a very large part on the Garbage Collector, and managing a system resources