Plan for D

[JN]

On Thursday, 13 May 2021 at 20:57:13 UTC, dogman wrote:
> Question to the core team. Whats the plan and roadmap for D ?
> a. are we planning to keep D just as a hobby language or a real 
> contender for industry use. Despite being complex, rust has 
> started to get adopted in industries. Whats our plan ?

Selection bias is in play here too. Rust is getting more popular, 
previously Go was starting to gain popularity also, but just as 
many languages succeed, many fail to reach the expectations. You 
have languages like Nim or Crystal, which have their own 
fanbases, but are relatively unknown in the general programming 
population (also, most programmers aren't really familiar with 
Rust/Go either). D is also in that category. You also have many 
languages that failed completely to gain attention and are dying 
away in programming language limbo.

But you also have languages which should succeed by most metrics, 
and yet they don't. Look at Dart. It's a well designed language 
(it's one of my favorite languages), it has good IDE support, it 
has Google behind it, and yet it never reached wide adoption. 
Outside of Flutter, the usage of Dart is very limited, and 
TypeScript took most of those usecases instead.

As for Rust, most people aren't flocking to Rust for memory 
safety or for GC-less memory management. Just like most people 
aren't flocking away from D because of GC (even if they claim 
it's because of GC). For many people, unless doing low level 
programming, memory management is more of an implementation 
detail.

Borrow checker isn't attracting people to Rust. It's a bonus, 
catching more bugs during compile time, but it's not the main 
feature. The main features that attract people to Rust is the 
cohesive story, good vision and a good ecosystem of tooling, 
libraries and bindings. Just like people did webdev with Python 
not because Python is great for webdev, but because it's good 
enough and easy to get started. With lots of libraries available, 
you can pip download flask, pip download pandas and make some 
nice dashboards within hours. Rust is similar to that extent. 
There are many packages, and you can expect many libraries to be 
existing, or at least if not existing, then the bindings to C/C++ 
libraries are available to cover that gap.

Both languages represent somewhat different mentality. Rust has a 
core team that is paid to work on Rust. These people can work on 
the design of the language and can force the decision whenever a 
problematic topic comes. D is mostly a volunteer project and 
doesn't have that luxury. Every problem that comes up needs a 
consensus to overcome. And in some cases the consensus is hard to 
get.

It is a chicken and the egg problem. Because D isn't very 
popular, it doesn't have the same level of ecosystem, and because 
it doesn't have the same level of ecosystem, it doesn't get 
popular. On the other hand, not every language needs to hit it 
big. I am satisfied with the state of the D and I've seen great 
improvements over the years. Dub really improved the ergonomics 
of using D, things like Code-D work fairly well (and get better 
every year also).

Sure, we can switch the language from garbage collection to 
manual memory management or reference counting. Will it change 
much? I doubt it, the people complaining about GC would just 
complain about RC. We would throw the existing ecosystem through 
the window, and there would be new bugs that come from the 
improvements.

Personally, I think what should happen is narrowing the scope of 
the language. I actually wish D went with GC fully, without 
giving escape hatches in form of @nogc. We shouldn't be chasing 
borrowing. Did that ever go anywhere? I don't even know if 
dip1000 works now, it's all hidden somewhere in spec documents. 
We don't have dozens of paid developers working on D full time. 
We have to manage with the resources we have, and spreading them 
thin over the language is not the optimal usage of such resources.