Future of D

[Imperatorn]

On Wednesday, 1 November 2023 at 01:00:53 UTC, Walter Bright 
wrote:
> On 10/30/2023 11:56 AM, Imperatorn wrote:
>> That's good to hear. Since D will be running on at least 50 
>> thousand devices within a year, it's kind of important.
>> 
>> It will be a very small project, that's why I feel confident. 
>> Just some things that are lacking, but no big deal, we can 
>> work around them.
>> 
>> We have compared 20 languages before coming to D, Nim, Go and 
>> C++ included. Our analysis showed that even though D is a 
>> smaller language, its learning curve is not steep and if you 
>> don't do weird stuff, the code is comprehensible and 
>> maintainable.
>> 
>> I have already put 3 packages on dub just to accomodate some 
>> missing features. dub works well and supports 
>> cross-compilation, which has been very easy to do for us.
>> 
>> Both from x64 Windows to aarch64 Linux and from x64 Linux to 
>> x64 Windows.
>> 
>> D is easy to learn, yet powerful, while also being efficient.
>> 
>> For example, take a look at the benchmark I, schveiguy and 
>> Sergi took part in:
>> https://github.com/jinyus/related_post_gen
>> 
>> We hope that D will continue to flourish and that we will be 
>> able to use it in the future
>
> Thanks for the kind words and contributions! I appreciate them.

I have yet to find a language except D that:
- Compiles to native
- Is fast
- Allows for both low and high level constructions
- Is from the C-family
- Has a package manager
- Is production ready
- Is not Rust ;)
- Allows you to be productive (has GC, this is very important)
...

C# AOT is close, but I don't trust it fully yet and it it's not 
available for some targets.

The most important feature for me/us is productivity.

That's the metric we use if a language is good or bad basically.

It doesn't matter if you have the "best language in the world" if 
you can't make something with it, or it takes so long that you 
loose your train of thought just because you're fighting the 
language instead of solving the problem, it's not very useful.

In our opinion the main goal of a language L is to reduce the 
time it takes to transform an idea into comprehensible code, ie 
minimize L(idea).

This is a concept that does not have anything to do with 
familiarity of the language at hand, but rather, given language L 
with no prior knowledge of L, produce the output xyz, you get the 
idea.

Benchmarks on the web should include development time, not only 
execution time.

It will of course be unfair if a language is of a family that you 
already have some familiarity with, but not much if you are 
familiar with a multitude of families :)

For example, not knowing *anything* about Nim, I was productive 
very fast because many things were just intuitive. Same with D. 
Or C#. And Nim and D doesn't have very much in common in terms of 
syntax.

I can't say the same thing for Rust for example. Just a step back 
in terms of productivity with minimal gain in safety. And 
frankly, most errors are logical if you're doing things right, 
not memory related. I can't remember if I ever had a memory 
safety issue in C# in 15 years, because I use managed memory, 
don't use pointers etc. And following MISRA guidelines + IAR 
C-STAT for example helps us when we *have* to write C. 
Unfortunately, you can't escape C yet, and I think we won't for 
years to come. Fortunately, I don't have to write C at the moment.

Don't use pointers, use the gc and be a good friend with the 
stack, goes a long way.

You don't need Rust to be a sane citizen of the programming world.

That's our current take on it anyway.