On Tuesday, 20 January 2015 at 23:47:44 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
>>> Concurrent GC is too expensive for a proper system level language.
>>>
>>
>> That is an unsubstanciated claim.
>
> And so is «pigs can't fly».
>

That is the old prove a negative bullshit.

You assert that something is too expensive for system language, which is not a negative, so the burden of proof is on you, substantiate your claim or you are just generating noise. Relying on cheap rhetorical trick is not going to fly (and you could add, no more than a pig).

On Tuesday, 20 January 2015 at 23:47:44 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 20 January 2015 at 23:17:28 UTC, deadalnix wrote:
>>> Concurrent GC is too expensive for a proper system level language.
>>>
>>
>> That is an unsubstanciated claim.
>
> And so is «pigs can't fly».
>
> You want to run the collection when the GC-memory is hot in caches. That basically means you want to run it right after you have traversed the data structure. E.g. clean up dead long lived objects after an iteration in a simulation.
>
> A concurrent GC will slow you down, push you out of (soft) real time boundaries and keep dragging irrelevant stuff into the caches.
>
> You want a fast and predictable GC that can fire often, not a slow "interleaved one" (one way or the other you need to compensate).

Strongly disagree, there is no silver bllet for memory and especially not for GCs.
I'd imagine a game developer would prefer a concurrent GC over a stop the world because it's better to run slightly slower than full freeze.

On Wednesday, 21 January 2015 at 01:05:28 UTC, weaselcat wrote:
> there is no silver bllet for memory and
Sorry, meant "silver bullet for memory management", bit tired : )

On 1/20/15 4:39 PM, ketmar via Digitalmars-d wrote:
> On Tue, 20 Jan 2015 16:30:14 -0500
> Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>> On 1/20/15 4:06 PM, ketmar via Digitalmars-d wrote:
>>> On Tue, 20 Jan 2015 15:51:17 -0500
>>> Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
>>> wrote:
>>>
>>> p.s. another point is that all mechanics compiler needs for doing such
>>> checks is already there, so it's not a huge change to compiler
>>> codebase. it's not something that requires adding a whole new analysis
>>> code.
>>>
>>
>> You can always put @nogc on the dtor if you want.
> seems that you completely missing my point. (sigh)
>

Nope, not missing it. The mechanics are there. You just have to annotate.

What's the first thing you do if you aren't sure your destructors are running?

~this() { writeln("in dtor"); }

oops, sorry, can't do that, it's @nogc! I don't think this is a tenable situation.

-Steve

On Tue, 20 Jan 2015 20:51:34 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> >> You can always put @nogc on the dtor if you want.
> > seems that you completely missing my point. (sigh)
> 
> Nope, not missing it. The mechanics are there. You just have to annotate.
that is where you missing it. your answer is like "hey, C has all mechanics for doing OOP with virtual methods and type checking, you just have to write the code!"

the whole point of my talk was "free programmer from writing the obvious and setup some red tapes for beginners".

> What's the first thing you do if you aren't sure your destructors are running?
> 
> ~this() { writeln("in dtor"); }
> 
> oops, sorry, can't do that, it's @nogc! I don't think this is a tenable situation.
but it is! first: we can loosen that restriction somehow for `debug` parts. your sample should be read like this then:

  ~this () { debug writeln("in dtor"); }

second: it's `writeln` who is bad. one of the reasons that motivated me to write my `iv.writer` was that `std.stdio.write` is not `@nogc`, and so it was completely unusable in any of my `@nogc` functions. even something that simple as `writeln("hi!")` was a disaster (both `@gc` and `@canthrow`).

this is a sign that Phobos needs some simple output API that can be used in `@nogc` and `nothrow` functions without hackery.

On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
> On Tue, 20 Jan 2015 20:51:34 -0500
> Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
> wrote:
>
>>>> You can always put @nogc on the dtor if you want.
>>> seems that you completely missing my point. (sigh)
>>
>> Nope, not missing it. The mechanics are there. You just have to annotate.
> that is where you missing it. your answer is like "hey, C has all
> mechanics for doing OOP with virtual methods and type checking, you
> just have to write the code!"

No, actually it's not. Adding @nogc to a function is as hard as writing "class" when you want to do OOP.

>
> the whole point of my talk was "free programmer from writing the
> obvious and setup some red tapes for beginners".

If he does it wrong, it gives him a stack trace on where to look. What is different here than any other programming error?

>> What's the first thing you do if you aren't sure your destructors are
>> running?
>>
>> ~this() { writeln("in dtor"); }
>>
>> oops, sorry, can't do that, it's @nogc! I don't think this is a tenable
>> situation.
> but it is! first: we can loosen that restriction somehow for `debug`
> parts. your sample should be read like this then:
>
>    ~this () { debug writeln("in dtor"); }
>
> second: it's `writeln` who is bad. one of the reasons that motivated me
> to write my `iv.writer` was that `std.stdio.write` is not `@nogc`, and
> so it was completely unusable in any of my `@nogc` functions. even
> something that simple as `writeln("hi!")` was a disaster (both `@gc`
> and `@canthrow`).

writeln("hi!") may need to extend a buffer, but probably not at this point. This is what I mean by "sometimes" allocates.

> this is a sign that Phobos needs some simple output API that can be
> used in `@nogc` and `nothrow` functions without hackery.

You may be able to, but I don't see the point. writeln can work perfectly fine for the most part inside dtors. But it can't be marked nogc.

-Steve

On 1/20/15 4:37 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Tuesday, 20 January 2015 at 21:29:40 UTC, Steven Schveighoffer wrote:
>> How's that? The current runtime aborts on memory allocation inside the
>> GC collection routine, it's not a memory safety issue.
>
> Spurious race conditions in memory deallocation patterns that remain
> undetected and cause random crashes after deployment are ok? That is not
> memory safety, it is "memory safety".

It's neither spurious, nor a race condition.

-Steve

On Tue, 20 Jan 2015 22:02:53 -0500
Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
wrote:

> You may be able to, but I don't see the point. writeln can work perfectly fine for the most part inside dtors. But it can't be marked nogc.
now, that's really nice. "it's wrong, it can fail, it even marked as one that can fail, but sometimes it works, so it's ok".

i'm off. there is no sense in trying to bring any sanity in this discussion. i'm sorry. Ola was right: seems that safety is not in a list of primary goals. it seems that it's not in a list of goals at all.

i hereby promise to not trying to propose anything in the future. it's pointless to proposing anything when wrong code is declared as "acceptable code". i'd better go with my fork from now on and stop polluting NGs with my misunderstanding.

On Wednesday, 21 January 2015 at 03:02:53 UTC, Steven Schveighoffer wrote:
> On 1/20/15 9:04 PM, ketmar via Digitalmars-d wrote:
>> On Tue, 20 Jan 2015 20:51:34 -0500
>> Steven Schveighoffer via Digitalmars-d <digitalmars-d@puremagic.com>
>> wrote:
>>
>>>>> You can always put @nogc on the dtor if you want.
>>>> seems that you completely missing my point. (sigh)
>>>
>>> Nope, not missing it. The mechanics are there. You just have to annotate.
>> that is where you missing it. your answer is like "hey, C has all
>> mechanics for doing OOP with virtual methods and type checking, you
>> just have to write the code!"
>
> No, actually it's not. Adding @nogc to a function is as hard as writing "class" when you want to do OOP.
>
>>
>> the whole point of my talk was "free programmer from writing the
>> obvious and setup some red tapes for beginners".
>
> If he does it wrong, it gives him a stack trace on where to look. What is different here than any other programming error?

Are you suggesting that newcomers should learn D by discovering it day by day from stack traces?

Actually there's nothing on the documentation about class destructors [1] that warns about that specific issue of the current (and default) GC.

[1] http://dlang.org/class.html#destructors

On Wednesday, 21 January 2015 at 03:03:50 UTC, Steven Schveighoffer wrote:
> It's neither spurious, nor a race condition.

How can you say that a priori? If you are using a framework, then subclass a node (which cannot be made @nogc), then do explicit deallocation to speed it up, then do multi-threading to speed it up... then any spurious memory leak due to races can result in crashes after deployment with this GC scheme.

The sad thing is that an innocent rare memory leak with C++ style memory allocation is less critical than a memory leak picked up by the GC.

That's bad marketing vs the C++ community which are highly sceptical to using a GC in the first place.