D vs Rust

[bearophile via Digitalmars-d]

On Sunday, 31 January 2016 at 15:44:37 UTC, Laeeth Isharc wrote:
> Guillaume Piolat
> "- D is a large language, not sure how much relatively to Rust. 
> I've heard Rust is complicated too."
> and yet, it's easy to get started if you know C.  one can be 
> quite quickly productive without having any experience of 
> template metaprogramming, CTFE, and the like, and gradually 
> absorb language features as you go.  Phobos is pretty readable, 
> on the whole.  I agree with bearophile about GC making it 
> easier in the beginning.
>
> bearophile:
> "I am sometimes able to write working D code almost as quickly 
> as Python code"
>
> Yes, indeed - that's my experience too.  I wonder what we could 
> do to make this most of the time, if not almost always, and for 
> less experienced programmers than you.  It wouldn't be 
> surprising to find that the things that tend to get in the way 
> fall in certain common categories.  Some people have applied 
> machine learning to compilers to study this - that's probably 
> beyond our resources for now, but the idea makes sense.  Adam's 
> and others' work on error messages might be part of the answer.
>
> Thank you for the colour on OcaML.  What could be done to 
> improve Algebraic and pattern matching?  The talk at the London 
> dmeetup was quite interesting, but I had the sense that was 
> fairly experimental at this stage.
>
> "There are several kinds of code that D allows you to write 
> quite better than Rust (generic application code, script-like 
> code, explorative scientific numerical code (like ndslice), 
> medium-integrity code, metaprogramming, compile-time 
> computations, template-level computations and specializations, 
> higher order template magic, and so on. "
>
> Should we make more of a feature of this in the intro page.  
> Tutorials per category showing the value?  And should the 
> Rosetta stone examples (many of which you wrote, as I 
> understand it) be more prominently featured?  Maybe even in the 
> code samples on the front page too.
>
> "In Ada you can be productive if you use it for the purposes it 
> was invented for, but most times you don't write that kind of 
> code."
> Thank you - yes that's what I figured, and it probably isn't 
> for me.  But I wanted to see if I was missing something.
>
> " I like languages that avoid me most common bugs,"
> I wonder what the most common bugs and traps are in D.  P0nce's 
> D idioms allude to some of them, but that isn't the focus of 
> what he writes.
>
> "I think D should relax and keep improving its strengths (like 
> C++ interoperability), fix some of its holes (safety, GC-less 
> programming, fixing its contract-driven programming experience, 
> etc), improve its medium-integrity coding, and keep going on as 
> usual, slowly getting better. The Rust and D niches are 
> sufficiently different, there's minimal overlapping in their 
> purposes and niches."
>
> Yes - I completely agree.  As Peter Thiel says, competition is 
> for losers.  Much better to have a monopoly that you have 
> earned (and have to keep earning).  I agree with Knuth that 
> language reflects thought and people intrinsically think 
> differently (this also being shaped by the domain) - he 
> welcomed the prospect of an expansion in the number and kinds 
> of language available.
>
> It's funny how the most negative critics in this forum and who 
> make diffuse statements about how D has lost the race often 
> don't seem to contribute much code to making things better.  
> Contrast with Manu, for example, who whilst spirited is 
> actually through actually using the language and reporting 
> concrete difficulties is directly driving the completion of 
> some features.
>
> Walter - sorry about that.  I need to get someone to help on 
> that front as I have so little time.  Should work now.
>
>
> Laeeth

Guillaume Piolat:

>What could be done to improve Algebraic and pattern matching?<

The number of developers working on D compiler, D design and 
Phobos is limited, and D is a large language. So it's better to 
focus the developing work on fixing and finishing the unfinished 
parts of D, instead of adding new ways to do the same things.

And even if you want new D features, there are more important 
things to think about, like GC-less coding, C++ interoperability, 
async/await, and so on.


>I wonder what the most common bugs and traps are in D.<

You have to take care of the less common bugs too if you want a 
reliable language.

And currently it's dead-easy to write unsafe code even in @safe D 
functions:

int[] foo() pure @safe {
     int[2] a = [10, 20];
     auto b = a[];
     return b;
}
void main() {}

Now that Rust is showing some "intellectual" competition with 
C++, Stroustrup is even starting to think about adding some 
memory safety to C++ (but it's hard for this to become a complete 
memory safety for C++):
https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines

Regarding the code reliability, D is better than C++11, but it 
can be further improved, as Ada2012/SPARK show. On the other 
hand, a higher reliability has a cost, and sometimes you don't 
want to pay it. Every language has to find its balance between 
many different design goals and desires.

Bye,
bearophile