9 ms·

The rust compiler will help you avoid a lot of common runtime errors. It comes at a cost of extra development time. The Rust philosophy values code correctness

by max76 7y ago

The rust compiler will help you avoid a lot of common runtime errors. It comes at a cost of extra development time. The Rust philosophy values code correctness over developer efficiency.

im_down_w_otp 7y ago
I'm confused by this sentiment. How efficient is a developer when producing things that are incorrect? Unless the goal is produce incorrect things, which seems unlikely. It seems like the philosophy prefers knowing ahead of time what's wrong over discovering it incidentally, and probably accidentally, after the fact.
- swsieber 7y ago
  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 7y 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 7y ago
      No, no one is talking about typing time--well at least not just typing time.
    - bluGill 7y 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 7y 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 7y ago
        Exactly, those are the trade offs. I'm not falling into appeal to extreme, even though I did point out an extreme.
  - kibwen 7y 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.
- jblow 7y ago
  This tradeoff obviously can’t be evaluated without considering quantities. What percentage of your bug load is reduced, at the cost of how much development time? That said, it’s not that simple. There are threshold effects (more than X amount of time = your company is dead) and intangibles (how do you feel while programming). But anyone making a blanket statement without considering these things is participating in a dumb internet argument.
- coldtea 7y ago
  >I'm confused by this sentiment. How efficient is a developer when producing things that are incorrect? How is this confusing? If it takes you 2 weeks with language X to write a sloppily written app, that works 99% of the time but has some errors -- and 2 months with Rust to write a version of the same app that has no errors, what you'd you prefer? Ever heard of "time to market"? What good it would be if you get it 100% right, and your competitor has their app already out, and captured all your potential customers? And even if time to market is not involved, would you really care for some occasional errors, if you get the majority of the functionality you want working just fine? If you build pacemakers and airplanes, the answer is yes. If you build regular websites, apps, and scripts, the answer might very well be no. That's the case, just the numbers (2 weeks, 100% etc) are made up.
  - steveklabnik 7y ago
    Yep. This is also why this is such a hard discussion to have: there’s no good way to get those numbers, and they vary by developer. What if that two months drops to three weeks, because you’ve put in the time to learn Rust better? What if that time to learn is a year? What if that 1% failure leads to six more months of developer time to fix? It’s a large, multi-variable problem. This is why it’s great that we have so many languages!
  - naasking 7y ago
    > What good it would be if you get it 100% right, and your competitor has their app already out, and captured all your potential customers? A constant stream of bugs have driven customers away before too, so if you're waiting in the wings with a bug-free/verified version of your competitor's program, you have a real shot at stealing their customers. First mover advantage is important, but so is quality if marketed properly.
    - mercer 7y ago
      Could you name some examples? I admit personally I'm inclined to agree with coldtea. But one example where I think the stability/quality of the software really did play an important role is WhatsApp. I remember when there were a bunch of competing services, but WhatsApp was the only reliable one. As far as I can tell there was nothing else that WhatsApp did better, and yet they 'won' (at least in Holland/Europe).
- jdblair 7y ago
  I'm a beginner at rust, but I think this sentiment is correct. I'm finding developing in rust to be similar to the overhead of test-driven development. When I do TDD, I spend a lot more time getting to my MVP, at the benefit of catching a lot of bugs early and hopefully writing more correct code. Usually with TDD I'm pretty astonished at the code that I think is correct that fails very simple tests. I have the assumption that once I am fluent in rust, more and more of the first code I write will be accepted by the borrow checker. The analogy is to C, where I don't really have to think consciously about, for example, assigning and dereferencing pointers. When I was a beginner C programmer (many years ago), I would write code and have it SIGSEGV immediately during test. Now that just doesn't happen unless I'm getting WAY too clever.
- jcelerier 7y ago
  > How efficient is a developer when producing things that are incorrect? Unless the goal is produce incorrect things, which seems unlikely. I have heard more than once that if we could spend a few hours less developing at the cost of having the product need to reboot every day or so, it was worth it. Of course it was no safety critical code, but in the end the only discriminant is money.
- nickpsecurity 7y ago
  "How efficient is a developer when producing things that are incorrect?" That software's users will use the product is the number one metric. They'll use it so long as it achieves their goal with the reliability or security they tolerate. That often means it can be kind of flaky in terms of reliability. The security can be arbitrarily bad so long as they don't know it. Sometimes they'll still use the product if they know security is bad because they need it. That's the baseline. From there, developers have to decide what's most beneficial among investments in more features, enhancements of existing features, new products/activities, or enhancing quality/reliability/security. They usually choose against that last set. So, doing the other things with the minimum quality that's acceptable makes the most economic and social sense.
tomjakubowski 7y ago
It's appealing to think there's a trade-off but in my experience there really isn't. I've been writing C++ and Rust for about the same length of time (4.5 years) and it at least feels to me like I am much better at shipping software when I write it in Rust: the work is done more quickly and I am more confident in its correctness.
- max76 7y ago
  I think that's why Rust is pulling a lot of developers from C/C++ and not languages like Python or Java.
atoav 7y ago
Rust isn’t really the language you’d use to fool around for a one-use-script. Although I must say that it replaced Python for most more complex programs for me. The type system makes it easier to read somebody elses code, even if they skipped all documentation. Rust certainly forces good practice onto you. But on bigger projects good practice doesn’t reduce your productivity, but instead increases it, let alone to speak of the increased sustainability. Rust’s module system in combination with it’s type system and ownership rules leave very little dark spots for the programmer where weird things can happen, even when your project grows big. And if weird things happen they are a breeze to track down compared to python, usually. Rust sort of nudges you into the right choices, when you program Rust the Rust way. If you are constantly fighting with the type system and the borrow checker that means you are probably still clinging to concepts you brought from other languages (at least it was like this for me). The moment I said: “Ok Rust, you won, from now on I will do it your way”, was the moment the compiler got my friend and things start to flow. Looking back I wonder why I ever thought I have to be able to force my abstractions into the code instead of taking a more data centric approach. Is the productivity significantly lower than with python? Only if you are not firm with the language

by max76 7y ago

The rust compiler will help you avoid a lot of common runtime errors. It comes at a cost of extra development time. The Rust philosophy values code correctness over developer efficiency.

im_down_w_otp 7y ago

I'm confused by this sentiment. How efficient is a developer when producing things that are incorrect? Unless the goal is produce incorrect things, which seems unlikely. It seems like the philosophy prefers knowing ahead of time what's wrong over discovering it incidentally, and probably accidentally, after the fact.

swsieber 7y ago
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 7y 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 7y ago
    No, no one is talking about typing time--well at least not just typing time.
  - bluGill 7y 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 7y 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 7y ago
        Exactly, those are the trade offs. I'm not falling into appeal to extreme, even though I did point out an extreme.
- kibwen 7y 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.
jblow 7y ago
This tradeoff obviously can’t be evaluated without considering quantities. What percentage of your bug load is reduced, at the cost of how much development time? That said, it’s not that simple. There are threshold effects (more than X amount of time = your company is dead) and intangibles (how do you feel while programming). But anyone making a blanket statement without considering these things is participating in a dumb internet argument.
coldtea 7y ago
>I'm confused by this sentiment. How efficient is a developer when producing things that are incorrect? How is this confusing? If it takes you 2 weeks with language X to write a sloppily written app, that works 99% of the time but has some errors -- and 2 months with Rust to write a version of the same app that has no errors, what you'd you prefer? Ever heard of "time to market"? What good it would be if you get it 100% right, and your competitor has their app already out, and captured all your potential customers? And even if time to market is not involved, would you really care for some occasional errors, if you get the majority of the functionality you want working just fine? If you build pacemakers and airplanes, the answer is yes. If you build regular websites, apps, and scripts, the answer might very well be no. That's the case, just the numbers (2 weeks, 100% etc) are made up.
- steveklabnik 7y ago
  Yep. This is also why this is such a hard discussion to have: there’s no good way to get those numbers, and they vary by developer. What if that two months drops to three weeks, because you’ve put in the time to learn Rust better? What if that time to learn is a year? What if that 1% failure leads to six more months of developer time to fix? It’s a large, multi-variable problem. This is why it’s great that we have so many languages!
- naasking 7y ago
  > What good it would be if you get it 100% right, and your competitor has their app already out, and captured all your potential customers? A constant stream of bugs have driven customers away before too, so if you're waiting in the wings with a bug-free/verified version of your competitor's program, you have a real shot at stealing their customers. First mover advantage is important, but so is quality if marketed properly.
  - mercer 7y ago
    Could you name some examples? I admit personally I'm inclined to agree with coldtea. But one example where I think the stability/quality of the software really did play an important role is WhatsApp. I remember when there were a bunch of competing services, but WhatsApp was the only reliable one. As far as I can tell there was nothing else that WhatsApp did better, and yet they 'won' (at least in Holland/Europe).
jdblair 7y ago
I'm a beginner at rust, but I think this sentiment is correct. I'm finding developing in rust to be similar to the overhead of test-driven development. When I do TDD, I spend a lot more time getting to my MVP, at the benefit of catching a lot of bugs early and hopefully writing more correct code. Usually with TDD I'm pretty astonished at the code that I think is correct that fails very simple tests. I have the assumption that once I am fluent in rust, more and more of the first code I write will be accepted by the borrow checker. The analogy is to C, where I don't really have to think consciously about, for example, assigning and dereferencing pointers. When I was a beginner C programmer (many years ago), I would write code and have it SIGSEGV immediately during test. Now that just doesn't happen unless I'm getting WAY too clever.
jcelerier 7y ago
> How efficient is a developer when producing things that are incorrect? Unless the goal is produce incorrect things, which seems unlikely. I have heard more than once that if we could spend a few hours less developing at the cost of having the product need to reboot every day or so, it was worth it. Of course it was no safety critical code, but in the end the only discriminant is money.
nickpsecurity 7y ago
"How efficient is a developer when producing things that are incorrect?" That software's users will use the product is the number one metric. They'll use it so long as it achieves their goal with the reliability or security they tolerate. That often means it can be kind of flaky in terms of reliability. The security can be arbitrarily bad so long as they don't know it. Sometimes they'll still use the product if they know security is bad because they need it. That's the baseline. From there, developers have to decide what's most beneficial among investments in more features, enhancements of existing features, new products/activities, or enhancing quality/reliability/security. They usually choose against that last set. So, doing the other things with the minimum quality that's acceptable makes the most economic and social sense.

tomjakubowski 7y ago

It's appealing to think there's a trade-off but in my experience there really isn't. I've been writing C++ and Rust for about the same length of time (4.5 years) and it at least feels to me like I am much better at shipping software when I write it in Rust: the work is done more quickly and I am more confident in its correctness.

max76 7y ago
I think that's why Rust is pulling a lot of developers from C/C++ and not languages like Python or Java.

atoav 7y ago

Rust isn’t really the language you’d use to fool around for a one-use-script. Although I must say that it replaced Python for most more complex programs for me. The type system makes it easier to read somebody elses code, even if they skipped all documentation. Rust certainly forces good practice onto you. But on bigger projects good practice doesn’t reduce your productivity, but instead increases it, let alone to speak of the increased sustainability. Rust’s module system in combination with it’s type system and ownership rules leave very little dark spots for the programmer where weird things can happen, even when your project grows big. And if weird things happen they are a breeze to track down compared to python, usually. Rust sort of nudges you into the right choices, when you program Rust the Rust way. If you are constantly fighting with the type system and the borrow checker that means you are probably still clinging to concepts you brought from other languages (at least it was like this for me). The moment I said: “Ok Rust, you won, from now on I will do it your way”, was the moment the compiler got my friend and things start to flow. Looking back I wonder why I ever thought I have to be able to force my abstractions into the code instead of taking a more data centric approach. Is the productivity significantly lower than with python? Only if you are not firm with the language