Hacker News Reader

Comment by Karrot_Kream | Hacker News Reader

But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior? You can't take this in isolation. The cognitive load of Rust takes a lot of defects out of the picture completely, but going off the beaten path in Rust takes a lot of design and patience.

People have been fighting this fight forever. Should we use static types which make it slower to iterate or dynamic types that help converge on error-free behavior with less programmer intervention? The tradeoffs have become clearer over the years but the decision remains as nuanced as ever. And as the decision space remains nuanced, I'm excited about languages exploring other areas of the design space like Zig or Nim.

View on HN

> But if Option A has 20 defects and takes a lot of effort to go down to 15 defects, yet Option B has 25 defects and offers a quick path to go down to 10 defects, then which option is superior?

Yes. If you change the entire premise of my example then things are indeed different.

Rust eliminates some defects entirely. Most other low-level languages do not. You would have to use a language like ATS to even compete.

That’s where the five-less-defects thing comes from.

Go down to ten effects? What are you talking about?

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.

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.

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.

Rust does no eliminate memory errors.

200+ memory safety errors were found in rust crates: https://www.infoq.com/news/2021/11/rudra-rust-safety/

I love rust, I think there's a good chance zig in its current state isn't the answer, but saying rust is totally memory safe is wrong. You drop into unsafe and people make the same errors C/C++ devs make.

The surface of exposure is much lower in Rust than in C/C++ however. It is unlikely you are writing your entire program in unsafe Rust, so you can still get a significant benefit from memory-safe safe Rust.

In C/C++ world, _everything_ is unsafe, so you can't even limit your exposure in the safer parts because you can do unsafe operations anywhere.

While true, that depends pretty much on which libraries you depend on, and the npm like ecosystem doesn't help in that regard.

Give me a break. 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.

Your comment is not some kind of gotcha. I can’t be bothered to give the long-form disclaimer in all of my follow-up comments. Read the context.

Reply on news.ycombinator.com