April 10, 2019
On Tuesday, 9 April 2019 at 00:07:33 UTC, Mike Franklin wrote:
> 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

There is a lot of focus on Rust these days just like there was a lot of focus on Java during the 90s. Since D came from that era, Java heavily influenced D. If D would have been written today maybe Rust would have influenced D, who knows.

For me Rust is a dead end. Rust works fine work for normal applications that keep to themselves. However, if you start to use Rust in embedded environments or call foreign languages, the Rust facade falls down. Intrusive algorithms, circular references, pointer magic will break Rust, it cannot handle it and it is very difficult to do easy stuff as you would do in C++. As soon you call a foreign interface which means casting a pointer from an object, the compiler looses track of it and the fancy memory management is useless and so is the benefit of Rust.

I think Rust type memory management is a fad because you have to constantly think about it and explicitly explain it to the compiler, a step in the wrong direction. The purpose of languages is to make things easier, not the other way around. Then again Rust was created for a large project with a lot of people in order make things parallel so they needed something to check that memory is shared correctly. It does that job well but it is not the Swiss knife, that can handle several levels of programming like C++.

Please no enforced borrow checker in D, then I could just as well manually manage my memory.

There is not much that can dethrone C++ right now. C++ owns the low level programming and no other languages give that exact control that C++ provides. D is close to C++ with a much nicer syntax but because it went a little bit to Java-ish it isn't really used in the low level area.

I talk a lot of about low level programming here, with higher level apps a wide range of alternatives opens up.

I've been evaluating a few languages as C++ a replacement. I've tested a few things that is important for me, how easy it was to implement it. I found out D was the best alternative, Nim in the middle and Rust at the bottom.

I like D but things like classes must be heap allocated limits it from displacing C++ for me right now. The better C path is the best way to go now as for the application languages there is much more fierce competition.


1 2
Next ›   Last »