Hacker News Reader

Comment by api | Hacker News Reader

The proper place for these is compilers, linters, fuzzers, unit tests, etc.

Rust does a pretty damn good job of preventing memory and threading errors for example. If it compiles and there is no unsafe it will run. It may not do precisely what you want but it will run and not crash.

View on HN

Doing the wrong thing is almost always worse than crashing.

You read that wrong. Rust eliminates a complete class of bugs. Memory safety bugs just don't exist.

Logic bugs are another class of bugs. Formal methods can help you with those though.

This is what I'm responding to:

> It may not do precisely what you want but it will run and not crash.

To me, that's a bad thing. I'd rather my software fail entirely than give incorrect results.

So what did I read wrong?

Rust programs can fail gracefully when they hit unexpected conditions - Safe Rust guarantees only extend to memory- and data-race safety. However, these tend to be table-stakes if one wants to make any kind of interesting statement about the semantics of programs, and there's a lot of ongoing work wrt. enabling this kind of use of Rust.

The implication there is that you may have other bugs (i.e. logic bugs, cache invalidation errors, off by one errors) but your program will not crash due to memory issues. It removes a class of errors.

It's not saying that it will provide wrong results in cases where it would crash otherwise due to memory errors.

Right. As I realized later, I have a bias: to me, Rust is solving the wrong problem.

Crashing is a useful tool when using the right language.

It's not about not crashing. C lacks memory safety, which leads to many bugs, many of which are security vulnerabilities. Memory safe languages such as python or rust just don't have those problems. The vast majority of languages are memory safe but only C is to-the-metal fast. Well, until Rust came along.

The really bad thing about C's memory unsafety is that crashing is pretty random.

Unless you use a plethora of tooling that patches over these shortcomings, wrong C code doesn't crash reliably (and even then it's not finding everything, only most bugs).

You can still crash voluntarily via abort! and panic! if that's what you prefer when your program encounters an error.

You like security vulnerabilities? I don’t think we are talking about the same thing at all. It’s perfectly easy to make Rust “crash” or log errors when it does the wrong thing, and to write unit tests for it.

Memory errors and threading bugs are never ever something you want.

What is the right problem? What would you _like_ Rust to be solving?

Erlang addresses the memory safety problem to my satisfaction. I'm not eager to embrace the verbosity of a language like Rust until we get closer to a guarantee that if code compiles, it's logically correct as well as safe.

The latter is not possible without some kind of strong AI. The compiler can’t know your intention.

Then I’ll be waiting a while!

Ok, now I see the point of confusion.

Erlang is my go-to language when I have the freedom to choose, and it is explicitly designed to crash when there's a mismatch between the expected and current state.

So, I was indeed missing the point of the statement.

There is a ton of memory-safe languages out there.

Reply on news.ycombinator.com