A strategic vision for D

[germandiago]

On Tuesday, 1 May 2018 at 12:26:25 UTC, Joakim wrote:
> I realize it's right before the conference, but I'd like to put 
> out a request for Walter and Andrei to spend five minutes 
> during your talks laying out some overarching strategy for how 
> you see D evolving. It could be during the keynotes or leading 
> off the Q&A panel, but I think it's worth laying a broad 
> strategy out there.
>
> Specifically, what uses do you see D being put to for the next 
> five years and how do we make it better in those directions.  
> For example, in what way you'd like to see D get better as a 
> language for writing apps, or what particular niches you see D 
> as a systems language doing well in first.
>
> For another example, here's what I'd say, ie my strategic 
> vision: the pendulum is about to swing hard back towards the 
> client, towards the billion and a half mobile devices sold each 
> year, and D is ideally positioned with its native efficiency to 
> do well there. However, since it's not the blessed language for 
> any mobile platform, like Kotlin or Swift, it will take much 
> work on libraries to pull that off.
>
> Some caveats: since D is not controlled by a company with W&A 
> as co-CEOs, they cannot obviously order people to follow their 
> vision. However, that should leave you free to really share 
> your unexpurgated thoughts, after all, we're all free to ignore 
> it. ;)
>
> Another is that perhaps D has chosen to evolve tactically as 
> opposed to strategically, carefully picking off wins with a new 
> feature or mode of programming but not following any grand 
> strategy, similar to how Linus Torvalds claims he didn't have 
> any grand vision for linux either. However, a strategic vision 
> can inspire people to work towards that goal, if there is one 
> to be shared.

My 2 cents. I have been following D for a long time and started 
using it in a very small project. I am a very long term C++ user.

Many people say that D does not offer anything over C++, 
improvements-wise. Or people tell you that there is Go and Rust. 
Because D does not have these fancy algebraic data types, or that 
borrow checker... no, no and NO. I think we do not need to enter 
that game. I have tried all 3. Here is my opinion.

1. Go --> excellent...!!! For what it does: namely, intensive 
communication client/server. It falls short of abstraction power 
in some areas, has no compile-time evaluation, no 
metaprogramming... though I must recognize it works pretty smooth 
for its simplicity.

2. Rust --> the borrow checker... excellent, in theory: in 
practice, as Andrei Alexandrescu once mentioned: you spend a lot 
of effort on something that in reality is not a problem most of 
the time. It is a problem, yes, but these problems can be avoided 
with much more lightweight solutions or simply, as D does, being 
able to avoid GC where it is needed. A much more practical 
solution. Rust has other things of value, such as Algebraic data 
types and Traits, but the borrow checker has a big impact for 
several reasons: it takes time to get used to, socially, people 
cannot use Rust from day one, so... you need added training for 
teams. But also remember... an "alien" type system makes it more 
difficult for integration with previous systems.

How should be D advertised? Well, I think that Ali Çehreli did a 
good job explaining in one of his keynotes the conveniencies of 
D, but this will not make people migrate. Why I am myself 
starting to take a look into D? I am a person that if I publish a 
project as open source, I want people to be able to contribute. 
Coding is, above all, a social activity, so:

- Come from Java, C#, want faster alternative? D will take little 
effort.
- Come from C, abstractions are too low level? D will take the 
same effort as alternatives with native performance, but you can 
start coding today.
- Come from C++ (like myself)? D is way cleaner and more 
convenient: modules, better metaprogramming, pervasive CTFE, 
*much better introspection* and also easy to learn.

Those are all good reasons, but, for me, what sets D apart is its 
level of integration with C/C++. If I come for D in the first 
place is because I can reuse my old code. This is true for most 
businesses: they have older code to integrate.

So my opinion is that D is a very pragmatic language that has 
this real, also management-perceivable advantages over all these 
nice algebraic data types integrated into the language and so on:

- if I pick up D in a team, it is very likely that D will be 
easier to pick up because many, many people know C++/Java/C# or 
similar things. This is a very important social factor and 
usually not mentioned or underestimated.
- if I have some C/C++ code to integrate, I can do it *way 
smoother* than with other languages to do it: please guys keep 
working on this.
- if I want safety, there are mechanisms that take you 90% there. 
Why would you pick up an alien like Rust where you have to 
relearn all, but not only that, you have to train full teams? 
This has a cost that is never analyzed seriously, but, on top of 
that, with an alternative mechanism such as GC + ability to 
disable it you can easily get there at a very low cost, because 
you skip a lot of the training for things such as the borrow 
checker.
- and last but not least, because of its insanely powerful 
metaprogramming: opening files at compile time + CTFE + 
metaprogramming, you can reach a level of integration with 
language bindings like Python or others that it is simply not 
possible with other languages, all at compile-time.

So, all in all, if I had to advertise D in a strategic way, it 
would be:

- the language for which migration for your team is going to work 
much smoother than the alternatives. I mean *much better*. 
Especially C/C++
- it does not feel alien -> another practical reason for saving 
training and moving things faster. Java/C#/C/C++ people can pick 
it up easily. And with native performance.
- powerful metaprogramming -> integration with other systems has 
an edge.
- native performance: fast code, but not only fast, you can avoid 
also the GC if you want and use it @safe ly.

What this means overall is that this language is the most 
practical of the pack for many reasons, compared to picking up 
the (in my opinion) almost academic Rust or the very specialized 
Go.

Some kind of slogans for D I could think of:

D: familiar, native and with a superior integration story: start 
being productive from day 1.
D: the pragmatic language, for people that need to get things 
done.

Or something similar. This is very true. We do not leave in a 
void, we have code, we have libraries from other languages, we 
need to integrate. D has an edge here, besides the learning 
curve, compared to any other native language.