Rant after trying Rust a bit

[deadalnix via Digitalmars-d]

On Sunday, 26 July 2015 at 23:21:50 UTC, Walter Bright wrote:
> If the template constraint is 'isInputRange', and you pass it 
> an 'InputRange' that is nothing beyond an input range, and it 
> compiles, it is JUST AS GOOD as Rust traits, without needing to 
> add 'isInputRange' to every template up the call tree.
>
> In fact, I do just this in my D dev projects. I have a set of 
> mock ranges that match each of the range types.
>

That is not enough, it has been covered. It is clear that this is 
what needs to be done for good testing. It is also clear and 
explained in this thread that this is not enough.

>> The problem is the exact same as for dynamic typing and 
>> unitests. A dynamically
>> typed function that expect a string can be test exhaustively 
>> with warious string
>> passed as arguments. Still, none knows what happen when passed 
>> an int, float,
>> array, object or whatever. Worse, it is either going to blow 
>> up in some
>> unexpected way or not explode and do random stuff.
>
> Flatly no, it is not at all the same. Dynamic typing systems do 
> not have constraints. Furthermore, dynamic typed languages tend 
> to do random s**t when presented with the wrong type rather 
> than fail. (Such as concatenating strings when the code was 
> intended to do an arithmetic add.) D does not, it presents the 
> user with a compilation error.
>

That is blatantly false and show more ignorance than anything 
else. For the precise example, concatenate with + is know to be 
bad in dynamic typing for this very reason. Even PHP got around 
that trap and pretty much only javascript got into that road. 
You'll find noone defneding this outside the Node.js crowd, but 
once you start thinking that a monothreaded event loop is the 
definition of scalable, you are already lost for science anyway.

But more generally there is a point. Dynamic languages tends to 
do random shit rather than failing. Hopefully, some won't. For 
instance python will fail hard rather than do random stuff when 
passed the wrong type.

If that was the problem faced, then using a type system would be 
pointless. Using something like python is sufficient.

>> The same way, instantiate your template with something it 
>> doesn't expect and you
>> get absurdly complex errors (and it is getting worse as phobos 
>> get more and more
>> "enterprise" with Foo forwarding to FooImpl and 25 different 
>> helpers).
>
> This is incorrect. In my D project development, when I send the 
> wrong thing, I get a list of the template instantiation stack.

Which is often 3 pages long.

> The bottom gives the method not found, and the stack gives how 
> it got there. I find it adequate in that it doesn't take much 
> effort to figure out where things went wrong.
>

That is learned helplessness. This is bad and we should feel bad 
to propose such a user experience. There are reasons why template 
are frowned upon by many devs, and this is one of them.

I even heard Andrei suggest at a conf to pipe the output of the 
compiler to head (he was talking about C++, but D suffer from the 
same problem in that regard). Yes it works, and yes you can 
eventually make sens of the error, but that is terrible user 
experience.

> BTW, when you discover that a constraint is wrong on a Phobos 
> template, please file a bug report on it.
>

It is not just phobos, but everybody's code. Why all this need to 
be done manually when the compiler could do it for us ?

Isn't it why we use computer in the first place ?

If I follow your post, one have to maintain a set of minimal mock 
to test instantiations, a constraint for the template and a body, 
the 3 of them requiring to be kept in synch over time while 
nothing checks it is.

That is completely unmaintainable.

>> The problem is the same, will it fail at call 
>> site/instanciation site with "I
>> expected X you gave me Y" or will it fail randomly somewhere 
>> down the road in
>> some unrelated part of the code, or worse, not fail at all 
>> when it should have ?
>
> If the constraint is InputRange, and the body assumes 
> ForwardRange, and I pass it a ForwardRange, and it works, how 
> is that 'worse'?

Maybe now my complexity is quadratic ? Maybe it doesn't do what 
it is supposed to do anymore, but else ?