Hacker News Reader

Comment by boustrophedon | Hacker News Reader

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.

View on HN

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.

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

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).

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!

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.

Reply on news.ycombinator.com