Rant after trying Rust a bit

[jmh530 via Digitalmars-d]

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).