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

On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
> 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.

Only one way to fix this. Volunteer.

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

Dub is endorsed by the leadership and is included in the same Github organization as the complier and the standard library

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

I attribute this to hype. Also, while dub may feel a little bare at times, I always think of the worse alternative in node, so many packages that are crap that they push out anything of value.

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

I don't know enough about rust to comment.

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

Maybe tooling would become easier to write, but in my personal experience, macros are much harder for programmers to understand than mixins, and much easier to abuse.

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

This would break so much code it's not even funny. I agree that immutable by default is the best paradigm, but as far as breaking changes go, you can only have so many before people abandoned a language.

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

Don't quite know what you mean here.

> 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 think that someone was working on this, but I think it got sidelined (as it should) to fixing RefCounted and other things in the std lib.

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

The tango vs Phobos issue has been mostly settled after the transition from d1 to d2, and the complier is a lot better now than it was.

> On the breaking part, the real issue is the "We're not going to break any code!" stance,

Who, in the leadership or a contributor, has ever said this.

I'm not at all familiar with Rust, so forgive me if I'm misinterpreting something.

On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
> 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.

I think I read that this may happen soon.

> Traits
> ------
> ...

You can make a `conformsToSomeInterface!T` template, and use `static assert`. D ranges, and the upcoming std.allocator, already use this sort of 'interfaces without polymorphism'.

Ex. `static assert(isInputRange!(MyCoolRange));`

> Macros
> ------
> ...

Most of what macros in C were used for are now done with templates, static if, etc. (I don't know how Rust's macros work). Tools could theoretically execute `mixin`, but it effectively requires a D interpreter. A library to do that would be really nice.

> Borrowing
> ---------
> ...

Look into `std.typecons.Unique`, though I've seen people posting that they don't like it (I haven't used it much; I had one use case for it, which was sending it through `std.concurrency.send`, but it doesn't work with that function).


Yes, D's community is pretty small. It's not something you can just code; you have to market the language. And it's the community that creates the many tools and packages.

Traits system is awesome and pure win. Pattern matching is not that game changing but helps often enough to feel important. Borrowship system is damn smart but totally impractical for most real-world cases. Macros are utterly horrible and pretty much unusable outside of advanced library internals.

Recently I attended local Rust meetup for curious newcomers - it was very interesting to observe reaction of unbiased devs not familiar with D at all. General reaction was "this is awesome interesting language that I would never use for any production system unless I am crazy or can throw away money like crazy". Because, well, productivity.

D has done many things wrong, but there is one right thing that totally outshines it all - it is cost-effective and pragmatical tool for a very wide scope of applications.

On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> 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.
>
> Only one way to fix this. Volunteer.

Yes, I agree. I haven't done much good for the D community,
although I believe some of the code I've written for mysql native
is in production.

Let me add a point for Rust somewhat related :)

Community
---------
The community is nice, helpful and doesn't condecent people.

On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> Expressions
>> -----------
>> This probably also falls in the "too late" category, but statements-as-expressions is really nice. `auto a = if ...` <- why not?
>
> Don't quite know what you mean here.

When "everything" is an expressions, you can write things like
    auto a = if(e) c else d;

In D you have to write
    type a = invalid_value;
    if(e) a = c;
    else  a = d;
    assert(a != invalid_value);


On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> (... snip [regarding phobos/tango runtime incompatibility] ...)
> The tango vs Phobos issue has been mostly settled after the transition from d1 to d2, and the complier is a lot better now than it was.

There are probably nothing in newer times that can be credited as
much pain as the incompatible runtimes of phobos and tango, but
I've still encountered a lot of compiler and phobos bugs. Yes,
it's just every 500 or so lines now, but I've only encountered
a couple of bugs in the C# compiler and a couple more in the .Net
library in several years - again credited to a lot more manpower
available.

On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> On the breaking part, the real issue is the "We're not going to break any code!" stance,
>
> Who, in the leadership or a contributor, has ever said this.

I'm pretty sure Walter Bright has said this on a lot of occations.
He seemed to believe a failure of adoption of D was due to the
constant breaking changes, which might be true.

On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> 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. (... snip ...)
> Dub is endorsed by the leadership and is included in the same Github organization as the complier and the standard library

I didn't know that. Very nice. I hope it's in a clean state when
it gets pulled in.

On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> While code.dlang.org has 530 packages, crates.io has 2610 packages, (... snip ...)
> I attribute this to hype. (... snip ...)

Yes, but the hype is probably driving even more developers to the
language, and I believe a large user-base is of paramount
importance for a language to become good.

On Wednesday, 22 July 2015 at 19:41:16 UTC, Jack Stouffer wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> Macros
>> ------
>> (... snip ...)
>
> Maybe tooling would become easier to write, but in my personal experience, macros are much harder for programmers to understand than mixins, and much easier to abuse.

I disagree. String mixins are much easier to abuse than hygenic
macros. String mixins allows anything, and while it offers
infinite possibilities, it also encourage abuse.

On Wednesday, 22 July 2015 at 19:52:34 UTC, Alex Parrill wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> Traits
>> ------
>> ...
>
> You can make a `conformsToSomeInterface!T` template, and use `static assert`. D ranges, and the upcoming std.allocator, already use this sort of 'interfaces without polymorphism'.
>
> Ex. `static assert(isInputRange!(MyCoolRange));`

Exactly. D is a lot more flexible, but looking just at
MyCoolRange, you cannot actually see it conforms to InputRange
without looking at the unittests (or wherever else the static
assert is inserted).

On Wednesday, 22 July 2015 at 19:52:34 UTC, Alex Parrill wrote:
> On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
>> Borrowing
>> ---------
>> ...
>
> Look into `std.typecons.Unique`, though I've seen people posting that they don't like it (I haven't used it much; I had one use case for it, which was sending it through `std.concurrency.send`, but it doesn't work with that function).

I haven't actually tried to recreate the stuff that Rust does with
types in D. I expect some of it is possible, but the addition is
things like Unique (which I haven't tried). And this escalates.
You end up with `Unique!(NonNull!(MyClass))` and probably even
more type decorators.

On Wednesday, 22 July 2015 at 19:52:34 UTC, Alex Parrill wrote:
> Yes, D's community is pretty small. It's not something you can just code; you have to market the language. And it's the community that creates the many tools and packages.

If I'm not mistaken, people of the D community have tried to
market the language quite heavily. I don't know why more people
haven't joined, and it's even more baffeling to see the comments
on Reddit calling D related posts spam and speaking negatively of
the marketing on a site where upvotes dictates the ranking on the
front page.

On Wednesday, 22 July 2015 at 20:43:04 UTC, simendsjo wrote:
> When "everything" is an expressions, you can write things like
>     auto a = if(e) c else d;
>
> In D you have to write
>     type a = invalid_value;
>     if(e) a = c;
>     else  a = d;
>     assert(a != invalid_value);


That's what the ternary expression is for:

auto a = e ? c : d;


Though the ternary is unnecessary with statements as expressions, common cases like this are handled.

On Wednesday, 22 July 2015 at 19:54:05 UTC, Dicebot wrote:
> Traits system is awesome and pure win.

Agreed.

> Pattern matching is not > that game changing but helps often
> enough to feel important.

The fact that you can use pattern matching many places makes it
very much a win.

    if Some(InnerClass::SomeType(value)) = some_call() {
        // here you can use `value`
    }

> Borrowship system is damn smart but totally impractical for most real-world cases.

I haven't used Rust enough to really have a voice on the subject.
It looks like a pardigm shift, and it might only take some getting
used to, but it might also be very difficult to use. There are
some big stuff written in Rust though - the rust compiler and the
servo browser engine. The fact that it makes a lot of errors
impossible is the exiting thing for me.

> Macros are utterly horrible and pretty much unusable outside
> of advanced library internals.

Not sure what you are referencing here. Macros expand to code. If
you compare this to string mixins, they are a lot easier for tool
writers, but a lot less powerful.

> Recently I attended local Rust meetup for curious newcomers - it was very interesting to observe reaction of unbiased devs not familiar with D at all. General reaction was "this is awesome interesting language that I would never use for any production system unless I am crazy or can throw away money like crazy". Because, well, productivity.

I'm having some problems interpreting this. This is people in
a Rust meetup - in other words, early adopters. And they thing
D is crazy "becuse productivity"? I don't understand what you
mean.

> D has done many things wrong, but there is one right thing that totally outshines it all - it is cost-effective and pragmatical tool for a very wide scope of applications.

Yes, D is pragmatic and extremely powerful and meldable to every
usecase.

On Wednesday, 22 July 2015 at 20:59:11 UTC, Adam D. Ruppe wrote:
> On Wednesday, 22 July 2015 at 20:43:04 UTC, simendsjo wrote:
>> When "everything" is an expressions, you can write things like
>>     auto a = if(e) c else d;
>>
>> In D you have to write
>>     type a = invalid_value;
>>     if(e) a = c;
>>     else  a = d;
>>     assert(a != invalid_value);
>
>
> That's what the ternary expression is for:
>
> auto a = e ? c : d;
>
>
> Though the ternary is unnecessary with statements as expressions, common cases like this are handled.

:) The example was written to save space. I recon you understand what I mean.

On Wednesday, 22 July 2015 at 21:03:52 UTC, simendsjo wrote:
> On Wednesday, 22 July 2015 at 19:54:05 UTC, Dicebot wrote:
>> Recently I attended local Rust meetup for curious newcomers - it was very interesting to observe reaction of unbiased devs not familiar with D at all. General reaction was "this is awesome interesting language that I would never use for any production system unless I am crazy or can throw away money like crazy". Because, well, productivity.
>
> I'm having some problems interpreting this. This is people in
> a Rust meetup - in other words, early adopters. And they thing
> D is crazy "becuse productivity"? I don't understand what you
> mean.

What I understood that he meant was that it was interesting to see the reaction of folks who have nothing to with D when they learned about Rust. So, they weren't likely colored by whatever preconceptions you'd get out of someone who's already invested in D. They were reacting to Rust without D being in the picture at all. And their reaction to Rust was that it was cool and interesting but that it would be crazy to use it in production, because it's not productive (or at least, they didn't think that it was) - presumably because some of its features make it too hard to use, but dicebot would have to elaborate.

- Jonathan M Davis