4 ms·

I'm not strongly opinionated on Rust specifically but I'm not sure: > Rust eliminates some defects entirely. Is really a true premise, and to the extent it is

I'm not strongly opinionated on Rust specifically but I'm not sure: > Rust eliminates some defects entirely. Is really a true premise, and to the extent it is true, is not a clear to me that it makes Rust better or safer than languages who don't eliminate this class of bugs. Unsafe exists, is widely used, and importantly is used in places where the hairiest versions of these bugs tend to live anyways. For safe code, I think it's clear that what we as programmers really care about is "how much does the language reduce the number of defects weighted by severity". If Rust reduces the number of memory bugs but increases other types of bugs due to increased complexity, that might not be a net win. Personally my guess is that Rust is a net win in this regard, but I don't think we have any evidence of that.

Karrot_Kream 4y ago
Another dimension to remember here is velocity. I've worked in heavily monadic Scala codebases where changes in object structure require minor refactors due to strict typing in the codebase. Changes that could be small in other languages would necessitate changes in our monad transformer stacks and have us changing types throughout the project. This eventually lead to engineer anxiety ("small changes take forever so I'm not willing to work on this codebase and explain to my manager why a schema change is taking so long") and aversion to project ownership. This codebase did materially have fewer defects than other, looser, codebases my team worked with. We got paged fewer times for this codebase than others. Unfortunately, other than a handful of engineers who loved working with monadic FP and were also busy, nobody wanted to touch the code and once the original authors left the team, the codebase went untouched. You could make the case that management should have let these engineers take more time to make these changes but in the meantime, other teams at the company built up high reliability ways of working in other languages and paradigms with higher velocity and similarly low defect rate. Defects alone aren't everything. You need to look at the big picture.
avgcorrection 4y ago
Yes, yes, yes. This was already covered in my original comment. > you don’t ever have to even think about those kinds of things as long as you trust the compiler and the Unsafe code that you rely on. Forgive if I don’t give the lawyerly disclaimer in all of my follow-up comments. Yes, you have to be able to trust the Unsafe code that you depend on.

Karrot_Kream 4y ago

Another dimension to remember here is velocity. I've worked in heavily monadic Scala codebases where changes in object structure require minor refactors due to strict typing in the codebase. Changes that could be small in other languages would necessitate changes in our monad transformer stacks and have us changing types throughout the project. This eventually lead to engineer anxiety ("small changes take forever so I'm not willing to work on this codebase and explain to my manager why a schema change is taking so long") and aversion to project ownership. This codebase did materially have fewer defects than other, looser, codebases my team worked with. We got paged fewer times for this codebase than others. Unfortunately, other than a handful of engineers who loved working with monadic FP and were also busy, nobody wanted to touch the code and once the original authors left the team, the codebase went untouched. You could make the case that management should have let these engineers take more time to make these changes but in the meantime, other teams at the company built up high reliability ways of working in other languages and paradigms with higher velocity and similarly low defect rate. Defects alone aren't everything. You need to look at the big picture.

avgcorrection 4y ago

Yes, yes, yes. This was already covered in my original comment. > you don’t ever have to even think about those kinds of things as long as you trust the compiler and the Unsafe code that you rely on. Forgive if I don’t give the lawyerly disclaimer in all of my follow-up comments. Yes, you have to be able to trust the Unsafe code that you depend on.