4 ms·

For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advan

by kd5bjo 6y ago

For most of these, the net result is that the compiler behaves strangely, but the programs that compile still work as intended. These are intermediate to advanced Rust concepts, and most programmers can eventually learn them from experience fighting with the compiler.

Someone 6y ago
If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”. That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”. The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership. For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules. Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.
- kd5bjo 6y ago
  You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else. My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.
- naasking 6y ago
  > If fighting with the compiler is necessary for learning I don't think "fighting the compiler" is a useful concept. No matter what language you're learning, you have to learn both the language's syntax and semantics. If your program barfs up an error at runtime because you made a semantic error the language forbids, that's no better than barfing up an error at compile time because you made semantic error the language forbids. So it's both more accurate and more precise to say that a language's semantics might be complicated or subtle, but the compilation step is orthogonal to the actual problem you're talking about.
  - kd5bjo 6y ago
    The difference in when the error is flagged is a large difference, though. Usually, runtime semantic errors won’t be flagged until the program tries to actually perform some nonconforming action. That lets the programmer work on unrelated issues by simply not exercising the defective path. Compile-time errors, on the other hand, ensure that the entire program meets some baseline of correctness before any of it is run. Neither is necessarily better or worse than the other, but they are categorically different things that have their own effects on the experience of writing programs.

by kd5bjo 6y ago

Someone 6y ago

If fighting with the compiler is necessary for learning, I think that would men lots of users would drop out, not “eventually learn”. That’s why lots of work has been done and still is being done to make that “work with the compiler’s help”. The thing is: in _any_ programming language, whenever you pass anything mutable to another function, you have to think about ownership. For the sake of reliability, rust makes that explicit, where other languages such as C and Java assume the programmers know what they are doing. To not make that too tedious for the programmer, rust also infers quite a few rules. Rust is getting better on both fronts. Its ability to infer ownership grows, and it gets better at reporting problems it can’t solve on its own.

kd5bjo 6y ago
You’re right, of course. To my mind, one way to classify how severe mistakes are is by looking at their potential consequences. For programming, there’s unpredictable, hard-to-identify bugs with far-reaching effects at oneend of the scale. On the other end are mistakes that announce themselves loudly, in a predictable way that are isolated from everything else. My original comment was a clumsy attempt to reassure ‘antpls and other Rust beginners that lifetime errors generally manifest as the less-troublesome kind on this scale.
naasking 6y ago
> If fighting with the compiler is necessary for learning I don't think "fighting the compiler" is a useful concept. No matter what language you're learning, you have to learn both the language's syntax and semantics. If your program barfs up an error at runtime because you made a semantic error the language forbids, that's no better than barfing up an error at compile time because you made semantic error the language forbids. So it's both more accurate and more precise to say that a language's semantics might be complicated or subtle, but the compilation step is orthogonal to the actual problem you're talking about.
- kd5bjo 6y ago
  The difference in when the error is flagged is a large difference, though. Usually, runtime semantic errors won’t be flagged until the program tries to actually perform some nonconforming action. That lets the programmer work on unrelated issues by simply not exercising the defective path. Compile-time errors, on the other hand, ensure that the entire program meets some baseline of correctness before any of it is run. Neither is necessarily better or worse than the other, but they are categorically different things that have their own effects on the experience of writing programs.