On Thursday, 8 February 2018 at 14:56:31 UTC, Adam D. Ruppe wrote:
> ooh better last sentence
>
>
> D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine.

If D had a decent garbage collector it might be a more convincing argument. 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.

I mean a good quality GC and seamless integration of manual memory management would be a pretty good argument to make, but D has neither of those ATM.

On Thursday, 8 February 2018 at 15:55:09 UTC, JN wrote:

> Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython).

I'm pretty sure CPython uses a mark-and-sweep GC together with reference counting.

On Thursday, 8 February 2018 at 17:03:58 UTC, Dave Jones wrote:
> On Thursday, 8 February 2018 at 14:56:31 UTC, Adam D. Ruppe wrote:
>> ooh better last sentence
>>
>>
>> D's GC implementation follows in the footsteps of industry giants without compromising experts' ability to realize maximum potential from the machine.
>
> If D had a decent garbage collector it might be a more convincing argument. 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.
>
> I mean a good quality GC and seamless integration of manual memory management would be a pretty good argument to make, but D has neither of those ATM.

What are D's limitations on do-it-yourself reference counting?

On Thursday, 8 February 2018 at 15:51:38 UTC, Adam D. Ruppe wrote:
> On Thursday, 8 February 2018 at 15:43:01 UTC, ixid wrote:
>> That's been said over and over and the message has not gotten through.
>
> It is almost never said! We always play by their terms and implicitly concede by saying "but we can avoid it" or "look -betterC".
>
> Reddit invades our space, and we fall back. Rust assimilates entire worlds, and we fall back. Not again! The line must be drawn here! This far, no further!

You're preaching to the choir here. Being able to add GC easily to a betterC base gives you the same utility and a much stronger story to tell people, optional GC sounds good.

Do you really think sticking with the current course on GC would gain more users than very slightly changing tack and making it something you add to a simpler base? I think the second of those will gain more users.

On Thursday, 8 February 2018 at 11:40:44 UTC, Seb wrote:
> On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote:
>> [...]
>
> https://github.com/dlang/druntime/pull/2057
>
>> [...]
>
> One of Andrei's student is working on this.
> I think she has been focusing on templated ==, <= and AAs so far and is now recently getting more into the GC business:
>
> [...]

Accompanied by a root cause analysis and learning how/why these were implemented at first place that prompts a D2 -> D3 and how to avoid such mistakes again so that D3 -> D4 is not required. :)

Just saying, techies can exhibit some managerial traits as well.

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.

On 2/8/2018 7:55 AM, 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. 

You can't separate the two. The Java and Go language semantics are designed around the GC.

On Thursday, 8 February 2018 at 18:08:59 UTC, Walter Bright wrote:
> On 2/8/2018 7:55 AM, 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.
>
> You can't separate the two. The Java and Go language semantics are designed around the GC.

I agree, however these languages would probably have been successful even without GC, using e.g. some form of automatic reference counting.

On Thursday, 8 February 2018 at 18:06:38 UTC, Walter Bright wrote:
> [snip]
>
> More precise GC exacts heavy runtime penalties, too, which is why attempts to add them to D have had mixed results.
>


See, there's your problem right there. Now if you replace the current GC with the slowest possible GC you can think of and then replace that with a precise GC. Then all the comparisons are gonna come out roses. /s

On Thursday, February 08, 2018 14:54:19 Adam D. Ruppe via Digitalmars-d wrote:
> On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote:
> > It feels like D has not overcome at least two major issues in the public mind, the built-in GC
>
> D is a pragmatic language aimed toward writing fast code, fast. 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

- Jonathan M Davis