Hacker News Reader

Comment by throwawaymaths | Hacker News Reader

Why should the first priority be memory safety? If the first priority is always memory safety, then rust should not have `unsafe` keyword. Existence of `unsafe` implies that, even rust, something is more important than safety

And, maybe rust is a poor choice because the language encourages layering hidden complexity and architecture astronauting.

View on HN

> If the first priority is always memory safety, then rust should not have `unsafe` keyword.

You can't have a system programming language without some unsafe layer because eventually you will have to interface with either the OS or a library written in another language and that's unsafe. Even languages like Java and C# have unsafe escape hatches for situations like these.

It seems then rust's first priority is "being a systems programming language", with memory safety being at best second.

Okay yes, the ability to print to stdout, an ultimately unsafe operation, is more important than upholding Rust's ideal of an entirely safe programming language.

> Why should the first priority be memory safety?

Because it's easy for beginners (and even experts) to create a memory safety bug, which is more critical than most bugs.

> If the first priority is always memory safety, then rust should not have `unsafe` keyword.

Err.. I suppose you don't fully understand how memory safety in Rust can be achieved. Every safe abstraction (function, trait, etc.) depends on unsafe code, either directly or transitively.

What's the difference between a safe function and an unsafe one, then? A safe function won't violate memory safety, no matter what combination of arguments passed to it.

Whether first priority is memory safety depends on a great many things about the software being created.

Because gov agencies say so?

Also, memory safety vulnerabilities is the largest class of vulnerability by count today by a large margin (70% of the total) and cost a lot of money to bigger companies.

As changing language stacks also cost a lot of money, there needs to be a strong incentive to do so. Getting memory safety without compromising applicability to the lowest levels of the stack is one such incentive.

Rust also doesn't have a lot of drawbacks, from my experience (professional use for years, coming from C++) and from recent reports from Google[1] (in particular, the learning curve steepness[2] and productivity penalty[3] are overstated).

[1]: https://opensource.googleblog.com/2023/06/rust-fact-vs-ficti...

[2]: Anecdotally, these ramp-up numbers are in line with the time we’ve seen for developers to adopt other languages, both inside and outside of Google. (Same report)

[3]: Overall, we’ve seen no data to indicate that there is any productivity penalty for Rust relative to any other language these developers previously used at Google. (Same report)

Reply on news.ycombinator.com