Hacker News Reader

Comment by roca | Hacker News Reader

> the big problem is that for applications that do need to do non-trivial reference semantics, Rust doesn't really offer much.

For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code. And in many cases someone else already wrote that library. For graphs, for example, there is petgraph.

> for applications that can easily fit within standard containers and standard allocation paradigms, C++ actually works really well already

Not at all. For example it is still easy to corrupt memory using C++ references. Just the other day I discovered a nasty little bug involving absl::hash_map: someone had written "map[i] = map[j]" which is unsafe if the element at i does not already exist --- it can trigger a rehash, invalidating the reference obtained by map[j].

View on HN

> For those applications you can almost always encapsulate the unsafe code in a data structure library with a safe interface, such that the library is a tiny fraction of the application code.

This is something I never understood. Given that a Rust application is running on top of an OS making OS calls... or uses a huge library like FFMPEG... The only safe portion is like the 1% of code being executed.

"such that the library is a tiny fraction of the application code"

I mean, your Rust app uses sockets to pull a video and save it with FFMPEG. The quantity of code executed to do that is like 99% unsafe and 1% safe. Right?

What are we talking about here? I can still find a bug in FFMPEG and ROP-exploit some code in the safe 1%, right?

The same languages and code Rust evangelists (and Mark Russinovich if not one) are blaming is the only code that makes Rust do something meaninful. Don't you agree?

Not all Rust programs are thin layers around libraries like FFMPEG. Why would you assume that?

Also, "if it can't be 100% safe right now all at once, then why even bother?" isn't very pragmatic.

> Why would you assume that?

It might not be using FFMPEG, but gdi32.dll, winsock2.dll, libc, etc. Correct?

Unless you run on 100% bare-metal, the "safe" code is still a tiny fraction.

What if my linked C library returns an invalid pointer? Rust will still make the assumption it might be valid and play along.

(that might be the reason why Rust likes to compile libraries/dependencies from source)

> Also, "if it can't be 100% safe right now all at once, then why even bother?" isn't very pragmatic.

Never said that. I only say that people thinks "unsafe" is just for a "tiny wrapper around a library" or as parent said "that the library is a tiny fraction of the application code."

At the end, it's not. If you consider the rest of the code that makes a Rust program run, then "library is a tiny fraction" is, in fact, the other 99% of your executing code, and that this code is unsafe (unless you run on 100% bare-metal).

The code in those libraries has been run billions upon billions of times, by billions of people. Sure, the libraries are written in unsafe languages, but they are incredibly battle-tested. Depending on your perspective, this may or may not be as good as a formal guarantee of correctness; at the very least there is a strong probabilistic argument for their correctness and safety.

The 1% of code that is your own will, upon creation, have been run precisely zero times, so there is no probabilistic argument to be made for its correctness. Safe languages let you exclude entire categories of mistakes even when your code hasn't been run yet, which seems obviously valuable.

> "encapsulate the unsafe code in a data structure library with a safe interface"

This was referring to using unsafe data structures in Rust by pulling in a Rust library so that your application code doesn't need any unsafe blocks itself. This is a huge win for your application code, even if there's other code that is still "unsafe".

It's true that writing code in safe Rust does not make other non-Rust code safe.

Nevertheless, the more code we write in Rust, the safer we will be. Especially because popular kernels and system libraries are often very well tested these days, whereas application code newly written by developers of varying skill levels likely won't be.

Reply on news.ycombinator.com