What is D?

[Mike Franklin]

On Monday, 8 April 2019 at 18:36:02 UTC, Abdulhaq wrote:

>> I also think D is more evolution than intelligent design.  It 
>> has evolved so much over the years, moving away from a "native 
>> java" to to more of a "better C++".  It think that has 
>> contributed much to its oddities, warts, and technical debt.
>>
>
> Yes it's evolved but was any other way practical?

No, evolution is great.  But you have to be willing to deprecate 
and break with the past to move forward.  You can't continue to 
carry all of your historical baggage with you as you progress.

> I do get the feeling that speed takes precedence over most 
> other features.

I don't see why it has to be one or the other.  This was a 
brilliant observation of Rust (https://youtu.be/d1uraoHM8Gg?t=68) 
  We don't have to always trade-off one thing for another.  We can 
have speed, expressiveness, and speed; they're not always mutally 
exclusive.

>> I think over the past few years it has become apparent that D 
>> has also become a case study in design by introspection:  See 
>> https://www.youtube.com/watch?v=Kn88228KSpQ for a presentation 
>> by Andrei elaborating on this.
>>
>
> I haven't watched this yet but keep meaning too. I have a 
> suspicion that it's a bit like duck typing so I should learn 
> more and find out if that's true or not. I can't help thinking 
> that that is what happened to ranges and now Andrei is trying 
> to tighten them up. No doubt I am totally wrong though!
>
> You're points about other languages are well taken and 
> interesting. D does seem to do better here. I think what you 
> value about D is very representative of the body of D users - a 
> very powerful and expressive systems language. Safety comes 
> below expressiveness.

Definitely not.  I very much want D to be statically-checked safe 
language.  I don't think you always have to make tradeoffs to get 
what you want.  I've once said that my ideal language would be 
Dust, basically D with a borrow checker.

IMO Rust's borrow checker is the greatest language innovation 
since C++. Unfortunately, it's only available in Rust.  D's 
trying with DIP1000 and DIP25, but this blog post 
(https://atilaoncode.blog/2019/03/13/issues-dip1000-cant-yet-catch/) illustrates it has come up short.  I would love to hear if anyone has any ideas to close that hole.  Walter?


> In broad terms, what would you change?

1.  Change the attitude towards change.  Bottom line is you don't 
have to be stuck with your mistakes.  With a well-managed 
deprecation process, or by creating a parallel, new, alternative 
implementations, D can move forward and leave its mistakes in the 
past; even the little ones.

With the coming copy constructors and the proposed ProtoObject, 
I'm cautiously optimistic that the attitude is changing.

I hope Andrei means what he says here: 
https://forum.dlang.org/post/q7j3s0$15n7$1@digitalmars.com

2.  Embrace what D does best (i.e. design by introspection). 
Utilize it in the compiler and the druntime to create a an opt-in 
continuum, again proposed by Andrei here: 
https://forum.dlang.org/post/q7j4sl$17pe$1@digitalmars.com  We 
have a couple of GSoC projects that, if chosen and are 
successful, could bring this closer to reality.

3.  D MUST be @safe by default to be taken seriously.  I realize 
it's superficial, but it matters.

4.  D MUST have an equally effective alternative to Rust's 
statically-checked memory safety and fearless concurrency to 
remain relevant.  DIP1000 and DIP25 give me hope, but D's missing 
something (that I can't quite put my finger on) as demonstrated 
in Atila's post above.

IMO, Rust's only feature is the borrow checker; the rest of the 
language stinks.  But, statically-checked memory safety is so 
fantastic Rust is destined for success.  If D had an equally 
effective mechanism for memory safety and fearless concurrency, 
there would be no reason for Rust to exist, and there would be no 
competition for D.

Mike