4 ms·

The optimal point on the tradeoff between developer velocity and performance/correctness depends a lot on the domain, in particular: -- How much usage do you e

by roca 6y ago

The optimal point on the tradeoff between developer velocity and performance/correctness depends a lot on the domain, in particular: -- How much usage do you expect to have? The more usage, the more important performance and correctness are. -- How critical is your application? The more critical it is, the more important correctness is. Also, the argument that you can spend developer time to increase correctness just by writing more tests works up to a point, but then it doesn't, because of diminishing returns. With Rust you can eliminate certain entire classes of bugs which tests will never reach.

throwaway894345 6y ago
> The optimal point on the tradeoff between developer velocity and performance/correctness depends a lot on the domain Agreed. This is what I was alluding to by "many applications absolutely index on developer velocity and performance". Note that it's even a bit more nuanced--within an application there are bits that are more sensitive than others. For example, the UI widgets are typically much less sensitive than the security, data privacy, and data integrity bits. Even still, I haven't noticed a frenzied rewriting of these systems from Go/C#/Java/etc into Rust, and I'm willing to bet that there's a fair amount of this kind of code implemented in JavaScript or Python. > How much usage do you expect to have? The more usage, the more important performance and correctness are. True, but this is a very low-value concern. Notably, hugely popular apps like Reddit can break altogether on a nearly daily basis (never mind more minor bugs, like some UI widget breaking) and they're still content to write in a completely dynamic language. > How critical is your application? The more critical it is, the more important correctness is. I think this is a much more important driver than usage, but relatively little software is so critical. As previously mentioned, there's lots of software that governs privacy and security systems that isn't being frenzily rewritten in Rust. Even OpenSSL, an application in which correctness is far more important than velocity, isn't considering a rewrite to Rust despite that it's written in a language with worse static verifiability than the Go/C#/Java tier. This is probably the kind of application that I would want to see in Rust--it's very sensitive to performance and correctness; which is to say, I think OpenSSL is very near the boundary at which writing in Rust makes economic sense (something that is very stable and very sensitive to correctness and performance). It's almost certainly not your web services. > Also, the argument that you can spend developer time to increase correctness just by writing more tests works up to a point, but then it doesn't, because of diminishing returns. With Rust you can eliminate certain entire classes of bugs which tests will never reach. Yeah, sorry, my brain was thinking one thing and my fingers typed another. I should have said "writing additional tests would recoup a bit less than the additional 4% that Rust would get you"; instead I typed "more". I missed the edit window, so I can't update my post.
- roca 6y ago
  I think we mostly agree. > Notably, hugely popular apps like Reddit can break altogether on a nearly daily basis (never mind more minor bugs, like some UI widget breaking) and they're still content to write in a completely dynamic language. Yes, but I wonder if people are sometimes being irrational here. You pay for those breaks out of the devops budget. Moving breakage to earlier in the developer cycle typically reduces the cost of fixing it. Regarding OpenSSL, there are a few reasons that isn't going to be rewritten in Rust anytime soon. The developers probably don't know Rust. OpenSSL runs in lots of places that don't have a Rust toolchain. Even if you rewrite it in Rust you're stuck with a bad API so why bother. In general there are more reasons against rewrite code in Rust than against writing new code in Rust ... and more reasons against writing new code in Rust that interfaces with old code than writing new greenfield code in Rust.
  - throwaway894345 6y ago
    > You pay for those breaks out of the devops budget. Only for organizations where "devops" means "ops". If your organization practices continuous deployment, then getting a bug fix out is no big deal (merge your PR to master and make sure the deployment doesn't fail); certainly no devops time is required. > Moving breakage to earlier in the developer cycle typically reduces the cost of fixing it. This axiom originates in the days of waterfall development and annual software deployments shipped to customers on shrink-wrapped physical media. It's not nearly as costly as our dated CompSci or SoftEng educations make it out to be. Your average web service isn't going to benefit on balance from moving from Go to Rust because any gains in finding/preventing bugs sooner are going to be dwarfed by the slowed pace of development. Of course, someone will point out that data races of the sort that Rust precludes are really hard to debug, which is true, but they're also very rare because request handling rarely requires parallel access to local resources (mostly things like database connections, where the locking is handled by the database library). The total cost of dealing with these for your average web application is still going to be dwarfed by the smaller tax Rust imposes on every change you make. Note that Rust has improved significantly, both by accepting more correct programs (laxer rules such as non-lexical lifetimes) and by improving tooling (rust analyzer). I'm not sure if they'll ever close the gap completely such that using Go/C#/etc are relegated to certain niche use cases, but I think it will continue to steal more and more of the application space that leans toward performance- or correctness-sensitive.

by roca 6y ago

throwaway894345 6y ago

> The optimal point on the tradeoff between developer velocity and performance/correctness depends a lot on the domain Agreed. This is what I was alluding to by "many applications absolutely index on developer velocity and performance". Note that it's even a bit more nuanced--within an application there are bits that are more sensitive than others. For example, the UI widgets are typically much less sensitive than the security, data privacy, and data integrity bits. Even still, I haven't noticed a frenzied rewriting of these systems from Go/C#/Java/etc into Rust, and I'm willing to bet that there's a fair amount of this kind of code implemented in JavaScript or Python. > How much usage do you expect to have? The more usage, the more important performance and correctness are. True, but this is a very low-value concern. Notably, hugely popular apps like Reddit can break altogether on a nearly daily basis (never mind more minor bugs, like some UI widget breaking) and they're still content to write in a completely dynamic language. > How critical is your application? The more critical it is, the more important correctness is. I think this is a much more important driver than usage, but relatively little software is so critical. As previously mentioned, there's lots of software that governs privacy and security systems that isn't being frenzily rewritten in Rust. Even OpenSSL, an application in which correctness is far more important than velocity, isn't considering a rewrite to Rust despite that it's written in a language with worse static verifiability than the Go/C#/Java tier. This is probably the kind of application that I would want to see in Rust--it's very sensitive to performance and correctness; which is to say, I think OpenSSL is very near the boundary at which writing in Rust makes economic sense (something that is very stable and very sensitive to correctness and performance). It's almost certainly not your web services. > Also, the argument that you can spend developer time to increase correctness just by writing more tests works up to a point, but then it doesn't, because of diminishing returns. With Rust you can eliminate certain entire classes of bugs which tests will never reach. Yeah, sorry, my brain was thinking one thing and my fingers typed another. I should have said "writing additional tests would recoup a bit less than the additional 4% that Rust would get you"; instead I typed "more". I missed the edit window, so I can't update my post.

roca 6y ago
I think we mostly agree. > Notably, hugely popular apps like Reddit can break altogether on a nearly daily basis (never mind more minor bugs, like some UI widget breaking) and they're still content to write in a completely dynamic language. Yes, but I wonder if people are sometimes being irrational here. You pay for those breaks out of the devops budget. Moving breakage to earlier in the developer cycle typically reduces the cost of fixing it. Regarding OpenSSL, there are a few reasons that isn't going to be rewritten in Rust anytime soon. The developers probably don't know Rust. OpenSSL runs in lots of places that don't have a Rust toolchain. Even if you rewrite it in Rust you're stuck with a bad API so why bother. In general there are more reasons against rewrite code in Rust than against writing new code in Rust ... and more reasons against writing new code in Rust that interfaces with old code than writing new greenfield code in Rust.
- throwaway894345 6y ago
  > You pay for those breaks out of the devops budget. Only for organizations where "devops" means "ops". If your organization practices continuous deployment, then getting a bug fix out is no big deal (merge your PR to master and make sure the deployment doesn't fail); certainly no devops time is required. > Moving breakage to earlier in the developer cycle typically reduces the cost of fixing it. This axiom originates in the days of waterfall development and annual software deployments shipped to customers on shrink-wrapped physical media. It's not nearly as costly as our dated CompSci or SoftEng educations make it out to be. Your average web service isn't going to benefit on balance from moving from Go to Rust because any gains in finding/preventing bugs sooner are going to be dwarfed by the slowed pace of development. Of course, someone will point out that data races of the sort that Rust precludes are really hard to debug, which is true, but they're also very rare because request handling rarely requires parallel access to local resources (mostly things like database connections, where the locking is handled by the database library). The total cost of dealing with these for your average web application is still going to be dwarfed by the smaller tax Rust imposes on every change you make. Note that Rust has improved significantly, both by accepting more correct programs (laxer rules such as non-lexical lifetimes) and by improving tooling (rust analyzer). I'm not sure if they'll ever close the gap completely such that using Go/C#/etc are relegated to certain niche use cases, but I think it will continue to steal more and more of the application space that leans toward performance- or correctness-sensitive.