My Long Term Vision for the D programming language

[bachmeier]

On Tuesday, 16 November 2021 at 21:00:48 UTC, Robert Schadek 
wrote:

> I fully understand that D is a community project and that we 
> can not tell the
> bulk of the contributors to work on issue X or milestone Y, but 
> we could ask
> them nicely.
> And if we follow our own project planing, they might just 
> follow along as well.

That's exactly the reason you need to lay out the plan clearly. 
It's a lot easier to get someone to contribute if they see the 
benefit. Feeling as if you're wasting your time is not motivating.

> ## phobos
>
> Batteries included, all of them, even the small flat strange 
> ones.

I agree. But only if the batteries are high quality (bug-free) 
and high quality (make it easy to do the important tasks). 
Otherwise it's better to leave them as third-party libraries that 
are simple to add to your project.

> ### GC
>
> To summarize, GC and GC only.

I'm not sure about "GC only", but yes, D is only relevant if it 
has a GC. Going after the GC-free segment of the market is like 
releasing OpenBSD-only binaries. It's just too small to be worth 
the effort, especially with a well-funded competitor already in 
that space.

> ### betterC
>
> betterC is, at best, a waste-by-product, if we have to use 
> betterC to write
> something for WASM, or anything significant, we might as well 
> start learning
> rust right now.

We don't want to promote it, but it does have an appeal to 
current C programmers, who often prefer an updated version of C 
to learning a new language.

> ### ImportC
>
> ImportC must have a preprocessor, or it is DOA.
> Shelling out to gcc or clang to preprocess, makes the build 
> system horrible
> which in turn will make the compiler library daemon thing 
> difficult to build.
> This is also important for the language interop, as I imagine 
> that most
> interop will go through a layer of C.
> When ImportC can use openssl 1.0.2s or so it is good enough.
> Having done some usage of openssl recently, my eyes can not 
> un-see the
> terribleness that is the openssl usage of C.

It makes sense to publish preprocessed versions of popular C 
libraries as Dub packages/standalone files that can be included 
in D programs. This can, to some extent, be done with what we 
already have.

Finally, on interop, there should also be support for R, Matlab, 
Julia, and Fortran. D is a natural fit for data processing. It 
also would not be that hard, since all of those languages are 
designed to work easily with C libraries. And all but Matlab (not 
sure about that one) are easy to call from D.