Rant after trying Rust a bit

[via Digitalmars-d]

Thank you for sharing your impressions! I think posts like this 
are really useful for the community, because it's important from 
time to time to take a look outside of the D ecosystem.

I've been watching Rust with interest myself, though I've mostly 
been a passive observer. Some of it's concept fascinate me. My 
general impression is that it's a lot stricter than D (good for 
correctness), but at the cost of expressiveness. I'm going to 
comment on some of your points below:

On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:

> Cargo
> -----

Very important. Fortunately, dub will be bundled with D in one of 
the next versions.

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

Not only that, but Rust does so much more with traits, e.g. 
closures. They seem to be a simple, yet powerful concept, that a 
big part of the language is built on.

http://blog.rust-lang.org/2015/05/11/traits.html

On the other hand, it is extremely restrictive in contrast to 
`static if()` and template constraints. D's approach is a lot 
more expressive and - at least for me - intuitive.

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

They're certainly cleaner than string mixins. On the other hand, 
they are really complex (and probably costly to implement, 
because they need to expose the AST). I don't know how 
representative it is, but I mostly use them for accessing 
aggregate members by name in meta-programming:

foreach(member; FieldNameTuple!T) {
     static if(typeof(mixin("T.init." ~ member)) : int) {
         // ...
     }
}

Or sometimes in cases where using recursive templates to build a 
list is too tedious.

I don't think AST macros would gain us much in D.

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

@safe by default would be really nice. It's easy to add `@safe:` 
at the beginning of your file, but large parts of e.g. vibe.d are 
not annotated and need to be called from @system functions. Maybe 
more inference would help here, too.

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

Yes, and it goes hand in hand with a more handy tuple syntax.

>
> Expressions
> -----------
> This probably also falls in the "too late" category, but 
> statements-as-expressions is really nice. `auto a = if ...` <- 
> why not?

Generally I find this an elegant concept. But in Rust, it leads 
to the distinction between expressions terminated with `;` and 
those without, which in turn makes it necessary to use braces 
even if you have only one statement or expression. This is 
something that I dislike very much.

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

Yes. I haven't given up hope that we can introduce a simplified 
version of this in D. It doesn't need to be as strict and 
pervasive as Rust's system. I'm still thinking about how to 
reduce that into something less complex without breaking too many 
of the guarantees it provides.