Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 13:37:15 UTC, Andrei Alexandrescu wrote: On 7/24/15 6:12 PM, deadalnix wrote: 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). No, that's not the case at all. There is a distinction: in dynamic typing the error is deferred to run time, in this discussion the error is only deferred to instantiation time. -- Andrei Runtime errors are a usability problem for users and maintianability problem for developers. Instatiation time errors are a maintianability problem for library authors and a usability problem for developers. I would argue that the latter is better than the former, but the poor developer experience of using Phobos is what made me move away from D a couple of years ago.
Re: Rant after trying Rust a bit
On Saturday, 25 July 2015 at 09:40:52 UTC, Walter Bright wrote: On 7/25/2015 12:19 AM, Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?= ola.fosheim.grostad+dl...@gmail.com wrote: The point of having a type system is to catch as many mistakes at compile time as possible. The primary purpose of a type system is to reduce flexibility. Again, the D constraint system *is* a compile time system, and if the template body uses an interface not present in the type and not checked for in the constraint, you will *still* get a compile time error. The idea that Rust traits check at compile time and D does not is a total misunderstanding. BTW, you might want to remove the UTF-8 characters from your user name. Evidently, NNTP doesn't do well with them. I think the point is that trait based constraints force compilation errors to be raised at the call site, and not potentially from deep within a template expansion. Template errors are stack traces coming from duck typed, compile time programs. Library authors can't rely on the typechecker to pick up on mistakes that may only appear at expansion time in client programs.
Re: Unused variables and bugs
I use Rust a reasonable amount, and the 'unused variable', 'unused field' and 'unused item' family of lints help a great deal in picking up mistakes early, especially when refactoring. Don't ask me to cite specific examples though - because they are enabled by default the issues are usually picked up and addressed early. Note that in order not to make the the lint more bearable, underscore-prefixed identifiers are ignored and you can also disable any lint can be disabled on an item-by-item basis using an attribute (although in practice the latter option is rarely used). I do think without those options it would be a massive pain. The underscore thing might not be an option for D though - do preceding underscores have a specific meaning in the prevailing D coding style?
