On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
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.
Rust only has structs. I'm not as familiar with them so it's not
as clear how they overlap with D's structs and classes. It seems
like you can put Rust structs on the stack or heap.
Others have already commented on how you can basically accomplish
the same thing with templates, static ifs, and assert. That was
my first thought as well. Nevertheless, I would add that Rust's
ability to use multiple traits in the template constraints is a
positive.
However, it seems like the essence of a trait in Rust is forcing
some user-defined type to implement some functionality. That
sounds a lot like an interface in D to me. In fact, Rust's traits
seem different from Scala and PHP traits in that I don't see any
examples with them using implementation. The two biggest
differences between Rust traits and D interfaces are 1)
inheritance of Rust traits (to my knowledge D does not have
inheritance for interfaces, am I wrong?), 2) Rust traits can be
easily used in template constraints. Those both seem like
positives to me, though I'm not sure if they can be easily
changed in D.
If you look at the Rust book's main example on traits. They use
them to implement a print_area function that can only be called
with structs that have a trait HasArea defined. Classes in pretty
much any OOP language could use inheritance to implement a
simpler version where print_area is a method instead of a
separate function.
To play devil's advocate, writing a bunch of code with
templates/static ifs/assert is definitely more confusing for
someone new to the language than Rust's traits are. A lot of the
D code makes quite a bit of sense when you understand how the
different ideas combine together, but it takes a while to figure
it out.
If traits were deemed important enough to add to D, I would
suggest just extending interfaces so that they have inheritance
and can be easily used in template constraints. I would be more
interested in seeing some of these OOP features come to structs,
but I have no idea how much work that requires. I feel like alias
this is hacky compared to real inheritance.
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.
It seems like D's Algebraic does not allow for recursive
Algebraic Types currently, whereas Rust's does. I'm honestly not
that familiar with the concept. Seems cool, but I'm not sure I've
ever really needed it.
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.
I feel like it's hard to separate borrowing from Rust's variety
of pointers (& is borrowed pointer, ~ is for unique pointer, @ is
for managed pointer). Nevertheless, I think having them part of
the language with relatively straightforward syntax is a positive
for Rust. Also, my understanding is that they are checked at
compile-time for safety (at least unique and managed).
However, I feel like borrowing and lifetimes have a bit of a
learning curve to them. I've read a few tutorials without a good
sense of them. I would probably need to program a bit in it to
grok it. I think part of it is that Rust has = potentially
meaning copy or move depending on whether it is defined. Perhaps
they need a separate move assignment, like <- and -> or something
(to steal syntax from R, even though that's not what <- and -> do
in R).
