How difficult would it be for D at this point to move towards a pay for what you use system that out of the box is betterC and requires the garbage collector to be explicitly imported?

It feels like D has not overcome at least two major issues in the public mind, the built-in GC and, more ludicrously, the D1 library split. Would there not be significant value in making this a D3 transition? As non-breaking as possible but moving the run time elements into libraries and potentially taking the opportunity to invert the defaults for things like safe and pure.

The story of this D3 transition to the public would then address the 'issues' head on, creating an easily conveyable story that these have been resolved. This appears to be the level on which a lot of language adoption works, at least between hearing about and trying a language. At the moment it's painful to see the endless criticisms of the GC and library split crop up whenever D is discussed. D is progressing technically but needs a 'story'.

On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote:
> How difficult would it be for D at this point to move towards a pay for what you use system that out of the box is betterC and requires the garbage collector to be explicitly imported?

https://github.com/dlang/druntime/pull/2057

> It feels like D has not overcome at least two major issues in the public mind, the built-in GC and, more ludicrously, the D1 library split. Would there not be significant value in making this a D3 transition? As non-breaking as possible but moving the run time elements into libraries

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:

https://github.com/dlang/druntime/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Asomzzz

> and potentially taking the opportunity to invert the defaults for things like safe and pure.

I think someone (Petar?) is working on a DIP for package-wide defaults.
The idea is simple, you tell the compiler once:

"Hey yo, listen up. I know that old code still needs to XXX (e.g. @system by default), but don't be a bad boy and let me opt-in into the cool new stuff by default, please"

I don't recall the exact details though.
Ideally it's like the -std=c++11 flag, i.e. you set it once in your dub.sdl and don't have to think about it again.

> The story of this D3 transition to the public would then address the 'issues' head on, creating an easily conveyable story that these have been resolved. This appears to be the level on which a lot of language adoption works, at least between hearing about and trying a language. At the moment it's painful to see the endless criticisms of the GC and library split crop up whenever D is discussed. D is progressing technically but needs a 'story'.

I don't think D3 is going to happen anytime soon (except someone forks the language).
Breaking changes are only done for critical things, e.g. when the compiler learns to detect new errors in your code.
Regarding the 'story', there's e.g. the excellent GC Series now (https://dlang.org/blog/the-gc-series) and things are moving forward though of course PR has always been one of D's weakest points.

---

Though if there's ever a D3, my list of things to be addressed is big

- no auto-decoding
- fix shared
- attribute bloat
- wrong defaults (e.g. @safe or final by default)
- C behavior without compiler warnings
- tuples (though it looks like they can be retro-actively added now that the use of the return of the comma operator is finally gone)
- Redesign Phobos with @nogc in mind
- remove the bloat from Phobos
- std.io (with streams)
- proper naming and structuring in Phobos (e.g. why is doesPointTo or RangePrimitive in std.exception), or "hello super-messy std.traits"
...

Some of these actually can be fixed with little or no breakage, but for most - if addressed - hell would break loose.

On Thursday, 8 February 2018 at 11:06:15 UTC, ixid wrote:
> How difficult would it be for D at this point to move towards a pay for what you use system that out of the box is betterC and requires the garbage collector to be explicitly imported?

I'm not sure if this is what you're looking for, but I've been trying to work on something like that, and have successfully submitted a few PRs:

Opt-in ModuleInfo
https://github.com/dlang/dmd/pull/7395
https://github.com/dlang/dmd/pull/7768

Opt-in Throwable
https://github.com/dlang/dmd/pull/7786

Opt-in TypeInfo
https://github.com/dlang/dmd/pull/7799 (not yet merged; someone please review it)

With all of the above PRs merged, the compiler will no longer complain about the above missing runtime features if your code doesn't use them.  It also allows one to create really small binaries with no dependencies.

Example 1
=========

object.d
--------
module object;

private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv, MainFunc mainFunc)
{
    return mainFunc(null);
}

main.d
------
void main() { }

dmd -conf= -defaultlib= main.d object.d -of=main
size main
   text	   data	    bss	    dec	    hex	filename
   1403	    584	     16	   2003	    7d3	main


Example 2
This will avoid linking in the C standard library and C runtime.  But you have to provide your own replacements.
=========

object.d
--------
module object;

extern(C) void __d_sys_exit(long arg1)
{
    asm
    {
        mov RAX, 60;
        mov RDI, arg1;
        syscall;
    }
}

extern void main();
private extern(C) void _start()
{
    main();
    __d_sys_exit(0);
}

main.d
------
void main() { }


dmd -c -lib main.d object.d -of=main.o
ld main.o -o main
size main
   text	   data	    bss	    dec	    hex	filename
     56	      0	      0	     56	     38	main

If you are creating a library to be consumed by another language, you just need to add an empty object.d file in your current directory.  I tried to remove that silly limitation, but it met resistance: https://github.com/dlang/dmd/pull/7825

I have a changelog PR describing all this at https://github.com/dlang/dmd/pull/7829, with the intention of it being available in the next DMD release, but I need my other PRs reviewed and merged before I can move forward.

This is just the tip of the iceberg, though.  After this stage, I would like to start tackling the overuse of TypeInfo in the coupling between the compiler and the runtime.  See this comment (https://issues.dlang.org/show_bug.cgi?id=18312#c2) for more about what I mean there.

Mike

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.

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.

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.

That's been said over and over and the message has not gotten through. With a pay for what you use approach the GC is just as available as it is now, and yes, I completely agree it's very useful and that the reaction to it is ludicrous. This is an illogical argument that we've lost so needs a new approach.

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!

On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe wrote:
> Garbage collection has proved to be a smashing success in the industry, providing productivity and memory-safety to programmers of all skill levels.

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. Python was also a smashing success, but it doesn't use a garbage collector in it's default implementation (CPython). Unless you mean garbage collection as in "not manual memory management"? But that still might not be as simple, because RAII would fall somewhere inbetween.

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!

Woot! Love it. :) Will save that quote you provided to use elsewhere. Thanks.

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?

On Thursday, 8 February 2018 at 14:54:19 UTC, Adam D. Ruppe 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.

Yes, absolutely! It's the reason I chose to start writing programs in D, because I had a background in C and Java, and wanted a fast, compiled language that would take care of the details for me. You can write programs quickly, and it's quick enough when running them, and can of course be tuned further through managing allocations/collections of the GC etc.