On 22/07/2015 19:47, simendsjo wrote:
> Long rant ahead - a bit dipsy..
>
> TL;DR: Rust has momentum, manpower and tooling. Tooling matters. Safe
> defaults.  Ergonomics like expressions and deconstructing rocks.
>

Tooling doesn't just matters. Tooling trumps everything else.

I've skimmed through this discussion and noticed a lot of discussion about Rust's traits vs. D's template constraints, as well as a few other minor language features. And while there is value in such discussion - as it may bring a better understanding or clarity about language design, or perhaps even a few language or library changes - don't be under the illusion that ultimately it will make any significant difference in language adoption, if the tooling quality differs a lot (and it does).

Minor differences, shortcomings even, between languages will only have a big impact for the kind of people that approach language preference with an "art appreciator" kind of mentality. An almost platonic/voyeristic approach. But for people building non-small, real-world projects (the "engineering" approach), tooling will trump everything else.

Only if the language differences where massive (say between D and Go), would perhaps tooling not trump language design... but even then, it would still be a big fight between the two!

-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On 07/30/2015 11:25 AM, Chris wrote:
> On Thursday, 30 July 2015 at 02:30:45 UTC, Ola Fosheim Grøstad wrote:
>> On Tuesday, 28 July 2015 at 09:29:28 UTC, Chris wrote:
>>> [1] I wonder what kind of bugs will be introduced, when if-else is
>>> used as an expression.
>>
>> I believe most Algol-like languages outside the C-family have it...
>
> So can you tell me what pitfalls there are?

What kind of special pitfall do you envision here?

> Sure people must have come across some nasty bugs related to this.

They are the intersection of nasty bugs involving ?: and nasty bugs involving if/else statements.

On Thursday, 30 July 2015 at 13:32:29 UTC, Timon Gehr wrote:
> On 07/30/2015 11:25 AM, Chris wrote:
>> On Thursday, 30 July 2015 at 02:30:45 UTC, Ola Fosheim Grøstad wrote:
>>> On Tuesday, 28 July 2015 at 09:29:28 UTC, Chris wrote:
>>>> [1] I wonder what kind of bugs will be introduced, when if-else is
>>>> used as an expression.
>>>
>>> I believe most Algol-like languages outside the C-family have it...
>>
>> So can you tell me what pitfalls there are?
>
> What kind of special pitfall do you envision here?
>
>> Sure people must have come across some nasty bugs related to this.
>
> They are the intersection of nasty bugs involving ?: and nasty bugs involving if/else statements.

My point was that any (new) feature introduces its own problems. Be it "everything is a statement" or built-in "bug prevention" (rigid features). While preventing certain types of bugs, new types may be introduced by features that have been introduced to prevent old bugs. It would be foolish to believe that most bugs will be erased, if only a language is rigid enough. As I said, I'll wait and see what Rust users have to say after a year or two.

On Thursday, 30 July 2015 at 11:46:02 UTC, Bruno Medeiros wrote:
>
> Tooling doesn't just matters. Tooling trumps everything else.


I don't agree. IMO reducing the need for tools would be a better solution.

For example, there's no need for a memory checker if you're writing in Python, but if you're writing in C, you better start learning how to use Valgrind, and that takes time.

Also there's Javascript's overabundance of tooling, with varying levels of quality, way too many choices (grunt vs gulp vs ..., hundreds of transpilers), and incompatibilities (want to use JSX and TypeScript together? Good luck).

To take it to the extreme, no matter how much tooling you write for BrainFuck, I doubt anyone will use it.

I think D goes in the right track by embedding things like unit tests, function contracts, and annotations into the language itself, even if the implementations could capitalize on them better than they do now.

On Thursday, 30 July 2015 at 14:23:34 UTC, Alex Parrill wrote:
> On Thursday, 30 July 2015 at 11:46:02 UTC, Bruno Medeiros wrote:
>>
>> Tooling doesn't just matters. Tooling trumps everything else.
>
>
> I don't agree. IMO reducing the need for tools would be a better solution.
>
> For example, there's no need for a memory checker if you're writing in Python, but if you're writing in C, you better start learning how to use Valgrind, and that takes time.
>
> Also there's Javascript's overabundance of tooling, with varying levels of quality, way too many choices (grunt vs gulp vs ..., hundreds of transpilers), and incompatibilities (want to use JSX and TypeScript together? Good luck).
>
> To take it to the extreme, no matter how much tooling you write for BrainFuck, I doubt anyone will use it.
>
> I think D goes in the right track by embedding things like unit tests, function contracts, and annotations into the language itself, even if the implementations could capitalize on them better than they do now.

It is not matter of agreeing or not. It is matter of fact. Language with good tooling work, language with poor tooling do not.

C++ did lose traction compared to java for a while and only came back up recently because Moore law is starting to not yield expected results and tooling dramatically improved.

Tooling is king, and beat language solution most of the time.

On 30/07/2015 15:23, Alex Parrill wrote:
> On Thursday, 30 July 2015 at 11:46:02 UTC, Bruno Medeiros wrote:
>>
>> Tooling doesn't just matters. Tooling trumps everything else.
>
>
> I don't agree. IMO reducing the need for tools would be a better solution.
>
> For example, there's no need for a memory checker if you're writing in
> Python, but if you're writing in C, you better start learning how to use
> Valgrind, and that takes time.

That doesn't go against what I said. Not having the need for a tool can be seen as identical to having the perfect tool (a tool you do not need).

Imagine I had said it this way: Tooling shortcomings trump all other shortcomings (like language design shortcomings). Not having the need for a particular tool, is like saying that tool has no shortcomings whatsover.


-- 
Bruno Medeiros
https://twitter.com/brunodomedeiros

On Wednesday, 22 July 2015 at 18:47:33 UTC, simendsjo wrote:
> Long rant ahead - a bit dipsy..
>
> TL;DR: Rust has momentum, manpower and tooling. Tooling matters.  Safe defaults.  Ergonomics like expressions and deconstructing rocks.
> [...]
> 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 :)

Mostly my experience, so far. If I have to choose the 'most important' things that Rust has that I'd *definitely* want in D, I'd pick (in order):

* A really nicely integrated package manager like Cargo that goes seamlessly hand-in-hand with DMD.
* DDMD
* An attribute or something that makes it explicit to the compiler that this type is a 'one time use' deal, and /exactly/ one-time-use (or, to be practical, zero-or-one times). Copying instances of objects of that type is done by `.dup`. (Like a non-Copy type in Rust currently.)
* Sum Data Types (`enum`s in Rust and `data D = VarA | VarB` in Haskell). As well as:
  * Pattern matching. `Algebraic!` is okay but pattern-matching that goes with it isn't PM.

But maybe that's for D 3.0 in 2030 or maybe another language... (I just want SML with at least D's speed T_T. I already got something /very roughly/ akin to ML's functors from D's template and mixin magic...)

On Friday, 31 July 2015 at 03:41:35 UTC, Enamex wrote:
> [...]
> Mostly my experience, so far. If I have to choose the 'most important' things that Rust has that I'd *definitely* want in D, I'd pick (in order):
>
> * A really nicely integrated package manager like Cargo that goes seamlessly hand-in-hand with DMD.
> * DDMD
> [...]

Ouch. Actually forgot second most important point (right before DDMD): a ~99.99% @nogc Phobos and better documentation for GC stuff. Right now docs say that `delete` is getting deprecated but using it on DMD .067.1 gives no warnings.

On Thu, Jul 30, 2015 at 7:19 AM, Chris via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> My point was that any (new) feature introduces its own problems... As I said, I'll wait and see what Rust users have to say after a year or two.
>

Except, as it was pointed out, this is not a new feature. It has been around in many languages way before Rust.

You don't have to wait a year or two, check what the experience of users of languages such as Scala, Haskell, F#, and OCaml has been like.

On Friday, 31 July 2015 at 09:08:00 UTC, Ziad Hatahet wrote:
> On Thu, Jul 30, 2015 at 7:19 AM, Chris via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> My point was that any (new) feature introduces its own problems... As I said, I'll wait and see what Rust users have to say after a year or two.
>>
>
> Except, as it was pointed out, this is not a new feature. It has been around in many languages way before Rust.
>
> You don't have to wait a year or two, check what the experience of users of languages such as Scala, Haskell, F#, and OCaml has been like.

It really doesn't mean much if you're talking about functional languages, because they're fundamentally different from imperative languages in how they're constructed. Almost everything in functional languages is an expression, and it works fine for them, but the way that code is written in those languages is also fundamentally different from how you'd write it in C, C++, Java, C#, D, etc. As I understand it, Rust is much closer to C++ and friends than a functional language, so how it interacts with the rest of the language is going to be quite different. That doesn't mean that it won't work just fine, but it does mean that the fact that it works fine in functional languages doesn't necessarily mean that it'll work well for Rust.

Now, there may be other imperative languages which have something similar - be it that all statements are expressions or that a larger subset of them are - so there may already be one or more languages out there which show that it can work just fine with an imperative language, but AFAIK, all of the languages you listed are either outright functional languages or lean heavily in that direction rather than being imperative. So, I don't think that experiences with those languages necessarily says much about how well it will work for Rust.

- Jonathan M Davis