3 ms·

There are many times where you don't need 100% correctness (e.g. prototypes, or edge cases that in practice are never hit) - I'd say it might be more accurate t

There are many times where you don't need 100% correctness (e.g. prototypes, or edge cases that in practice are never hit) - I'd say it might be more accurate to say that Rust makes it harder/less convenient to take out technical debt. I discovered a bug that could potentially be triggered in the codebase where I work, but never has. It's about 5 years old. You don't actually always need technically correct - sometimes you want practically correct, where "practically" covers a huge spectrum.

melling 8y ago
I think we're talking about typing time, right? Because if say, 75% of your time is spent debugging in an "regular" language then you really aren't saving much time by reducing the amount of code you must write. If we could reduce programming to typing in mostly correct code then software development will be much faster, even if the code we type is 50% longer.
- learc83 8y ago
  No, no one is talking about typing time--well at least not just typing time.
- bluGill 8y ago
  That 75% of the time is spent with a mostly functioning program though. There are a lot of cases where getting something now is worth overall spending 10x as much time getting it right latter. Of course everyone wants the best of both worlds: everything now, zero bugs. Fast, cheap, right: pick two applies despite everyone wanting all three.
  - melling 8y ago
    Where did the 10x come from? I thought we were discussing the trade-offs of typing a little more to guarantee correctness, or at least eliminate a class of software errors. You're doing that Appeal to the Extremes Fallacy: https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/30/Appeal-to-Extremes https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFalla...
    - bluGill 8y ago
      Exactly, those are the trade offs. I'm not falling into appeal to extreme, even though I did point out an extreme.
kibwen 8y ago
> I'd say it might be more accurate to say that Rust makes it harder/less convenient to take out technical debt. I'll disagree with this one. Refactoring old and rarely-touched code is bliss when working under a strong type system, at least relative to dynamic or weakly-typed languages. The key to the timely resolution of technical debt is to allow things to be updated in piecemeal rather than in one enormous burst; this requires solid abstraction boundaries and encapsulation, both of which are provided by types (in addition to other features of a language, such as a module system). The fact that Rust so heavily discourages global state is another point in its favor. We can agree that there are contexts where correctness is less important than velocity, e.g. prototyping, though languages that front-load correctness at the expense of velocity are going to produce less technical debt in the first place, because the debts can be paid off before they accrue interest.

melling 8y ago

I think we're talking about typing time, right? Because if say, 75% of your time is spent debugging in an "regular" language then you really aren't saving much time by reducing the amount of code you must write. If we could reduce programming to typing in mostly correct code then software development will be much faster, even if the code we type is 50% longer.

learc83 8y ago
No, no one is talking about typing time--well at least not just typing time.
bluGill 8y ago
That 75% of the time is spent with a mostly functioning program though. There are a lot of cases where getting something now is worth overall spending 10x as much time getting it right latter. Of course everyone wants the best of both worlds: everything now, zero bugs. Fast, cheap, right: pick two applies despite everyone wanting all three.
- melling 8y ago
  Where did the 10x come from? I thought we were discussing the trade-offs of typing a little more to guarantee correctness, or at least eliminate a class of software errors. You're doing that Appeal to the Extremes Fallacy: https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFallacies/30/Appeal-to-Extremes https://www.logicallyfallacious.com/tools/lp/Bo/LogicalFalla...
  - bluGill 8y ago
    Exactly, those are the trade offs. I'm not falling into appeal to extreme, even though I did point out an extreme.

kibwen 8y ago

> I'd say it might be more accurate to say that Rust makes it harder/less convenient to take out technical debt. I'll disagree with this one. Refactoring old and rarely-touched code is bliss when working under a strong type system, at least relative to dynamic or weakly-typed languages. The key to the timely resolution of technical debt is to allow things to be updated in piecemeal rather than in one enormous burst; this requires solid abstraction boundaries and encapsulation, both of which are provided by types (in addition to other features of a language, such as a module system). The fact that Rust so heavily discourages global state is another point in its favor. We can agree that there are contexts where correctness is less important than velocity, e.g. prototyping, though languages that front-load correctness at the expense of velocity are going to produce less technical debt in the first place, because the debts can be paid off before they accrue interest.