Long rant ahead - a bit dipsy..
TL;DR: Rust has momentum, manpower and tooling. Tooling matters.
Safe defaults. Ergonomics like expressions and deconstructing
rocks.
I'm reluctantly confessing that I've had a small affair with Rust
recently. While I think D is a really good language, there are
several things I don't agree upon. Some are caused by historical
reasons, some are caused by the lack of peer review. Lets look at
a couple of things I think looks exiting about Rust after a bit
experimentation.
Manpower
--------
Silly stating this as why I have been playing with Rust, but it's
probably one of the main reasons. Rust has momentum and a lot of
manpower and well as some big compinies behind it. It should be
of secondary importance, but this is something that really shows
in the quality of Rust.
I've been using D on and off since 2007, and the lack of manpower
shows in every aspect of the language, design and ecosystem. Rust
has a pretty nice ecosystem and tools given its very young age.
Cargo
-----
Rust has a default package manager much like Dub. The main
difference is that Cargo has been endorsed by the Rust team and
is an official product. This means it works very well with the
compiler and feels like an integrated part of the language. Dub,
on the other hand, is a product from the outside, and
unfortunately, it feels this way too. Having Dub become the
endorsed package manager for D sounds like a very good idea for
me. In order to do this, some breaking changes might be necessary
(I haven't used much D or Dub recently though..). If so, a good
time to introduce breaking changes would be before integrating it
into the "core" D ecosystem.
The effects of Cargo is very visible by looking on the amount of
libraries on https://crates.io as opposed to
http://code.dlang.org.
While code.dlang.org has 530 packages, crates.io has 2610
packages, and this is even if Rust is very new. Dubs repository
website is a lot better than Rusts though :)
Traits
------
I think the ability to express an interface without buying into
inheritance is the right move. The alternative in D is specifying
the behavior as a template and verifying the contract in a
unittest for the type.
Algebraic data types
--------------------
Haven't looked into `Algebraic!`, so I won't start bashing D here
:) But given the lack of pattern matching, I doubt it will be as
pretty as Rust.
Macros
------
I haven't written more than extremely simple macros in Rust, but
having macros that is possible for tools to understand is a win.
Templates and string mixins is often used for this purpose, but
trying to build tools when string mixins exists is probably
extremely hard. If D had hygenic macros, I expect several
features could be expressed with this instead of string mixins,
making tooling easier to implement.
Safe by default
---------------
D is often said being safe by default, but D still has default
nullable references and mutable by default. I don't see it being
possible to change at this stage, but expressing when I want to
be unsafe rather than the opposite is very nice. I end up typing
a lot more in D than Rust because of this.
Pattern matching
----------------
Ooooh... I don't know what to say.. D should definitely look into
implementing some pattern matching! final switch is good for
making sure all values are handled, but deconstructing is just so
ergonomic.
Expressions
-----------
This probably also falls in the "too late" category, but
statements-as-expressions is really nice. `auto a = if ...` <-
why not?
Borrowing
---------
This is probably the big thing that makes Rust really different.
Everything is a resource, and resources have an owner and a
lifetime. As a part of this, you can either have multiple aliases
with read-only references, or a single reference with a writeable
reference. I won't say I have a lot of experience with this, but
it seems like it's not an extremely unergonomic trade-off. I
cannot even remotely imagine the amount of possible compiler
optimizations possible with this feature.
----
Why have I been looking at Rust?
I haven't been using D in production since 2008, which was an
utterly disaster. I did some work on the native mysql client, but
that was mostly making the code more D than C. Some small
experimentations thereafter.
The constant breakage in the language and standard library
haven't been an real issue for me as I haven't used it in
production - the problem when I used it was partly the phobos vs
tango with incompatible runtimes together with an extremely buggy
compiler. On the breaking part, the real issue is the "We're not
going to break any code!" stance, while each release still breaks
every codebase. The effect is that a lot of really long-term
necessary breaking changes is never accepted - the only breaking
changes is the unintended breaking changes! I'm in the "break-it"
camp. If you don't mind living with historical baggage and want
an expressive language, you can use C++. Why should D try to stay
with the baggage it has only recently acquired because of the
lack of manpower? I've recently been to job interviews, and none
of them ever heard of D...
After following Rust for some time (instead of following D!) and
now spending some time playing with it, I have to say that Rust
has several things going for it: manpower, momentum, tooling.
There are also really nice things like "everything" being an
expression, pattern matching and the compiler as a library.
But again... After playing a bit with Rust, I feel it lacks a lot
in expressive power. D has templates, template mixins, alias
this, string mixins, opDispatch etc. In my little time with Rust,
I've seen several pages of generic constrains that is expressible
in a couple of lines with D. I've seen copy/pasted code that just
isn't necessary when you code in D.
Anyways - my little ramblings after trying the Rust programming
language while I haven't used D in a long, long while (But I'm
still here now, as I'm not sure Rust is able to express
everything that is possible with D). Looking forward to following
D again :)
