Rant after trying Rust a bit

[Tofu Ninja via Digitalmars-d]

On Saturday, 25 July 2015 at 00:45:06 UTC, Walter Bright wrote:
> On 7/24/2015 3:12 PM, deadalnix wrote:
>> On Friday, 24 July 2015 at 19:10:33 UTC, Walter Bright wrote:
>>> If I have a call tree,
>>> and at the bottom I add a call to interface X, then I have to 
>>> add a constraint
>>> that additionally specifies X on each function up the call 
>>> tree to the root.
>>> That is antiethical to writing generic code, and will prove 
>>> to be more of a
>>> nuisance than an asset.
>>>
>>> Exactly what sunk Exception Specifications.
>>
>> In many language you have an instaceof keyword or something 
>> similar. You'd get :
>>
>> if (foo instanceof X) {
>>    // You can use X insterface on foo.
>> }
>>
>> vs
>>
>> static if (foo instanceof X) {
>>    // You can use X insterface on foo.
>> }
>>
>> The whole runtime vs compile time is essentially an 
>> implementation detail. The
>> idea is the very same.
>>
>> The most intriguing part of this conversation is that the 
>> argument made about
>> unitests and complexity are the very same than for dynamic vs 
>> strong typing (and
>> there is hard data that strong typing is better).
>>
>> Yet, if someone would make the very same argument in the case 
>> of dynamic typing,
>> both Walter and Andrei would not give it a second though (and 
>> rightly so). Yet,
>> nowhere the reason why this differs in ay that make the 
>> cost/benefit ratio shift
>> is mentioned. It is simply asserted as such.
>
>
> I don't see how this addresses my point at all. This is very 
> frustrating.

The same "problems" that you are claiming will happen with with 
the compile time interfaces are the exact same as the problems 
that happen with normal types systems.

With the normal type system, if somewhere down the call tree you 
need X you need to either update your interface, make a new one 
and add it to the whole call tree, or cast.

If somewhere down the call tree a template needs X, then with 
this compile time interface thing, you would need to either 
update your interface, make a new one and add it to the whole 
call tree, or do some kind of static cast.

ITS THE SAME.

Your arguments for why not to do it are even the same that people 
give for dynamic typing, and we know how well that works out.

Current template types work like duck typing, which works, but 
its error prone, and your argument of unittests is obviously bad 
in the context of duck typing. We want a real type system for our 
template types.

You may be thinking, but why would you want a type system for 
template types, why not just use the normal type system? Well 
because we want static dispatch, and compile time introspection 
and static if and all the other great things we have at compile 
time.