Hacker News Reader

Comment by ubj | Hacker News Reader

I've recently seen a lot of Rust rewrite projects that have talked about how much they've been required to use unsafe blocks. I'm currently in process of my first C++-to-Rust rewrite, and I haven't needed to reach for unsafe at all yet.

What kinds of projects or C++ features are requiring such high usage of unsafe? I'm not implying that this is bad or unnecessary--I'm genuinely curious as to what requires unsafe to be used so frequently. Since by all accounts unsafe Rust can be harder to use than C++, this may help inform me as to whether I attempt using Rust in future rewrites.

View on HN

I agree that in my experience, little unsafe is needed. However, (from an earlier article in this series):

> This project is a library that exposes a C API but the implementation is C++, and it vendors C libraries (e.g. mbedtls) which we build from source. The final artifacts are a `libfoo.a` static library and a `libfoo.h` C header.

In this case, this project is doing a lot of FFI, both exposing C, as well as calling into C libraries. That's unsafe. Which is a good example of a project that may use unsafe more than the average Rust project.

My feeling was that this rewrite is not actually "done". Sure, all their C++ has been converted to Rust, but it seems like there's a lot of unsafe that they could rewrite in safe Rust.

And for the C libraries they vendor in, assuming none of them are exposed directly in their public API, it's likely they can replace them with Rust libraries with equivalent behavior. mbedtls seems like a good example of that; certainly it wouldn't be a small effort to switch to rustls, but it might be worth it to do so. And even if they didn't choose to do that, I just did a quick search on crates.io, and it looks like there are safe wrappers for mbedtls.

Ah, that makes sense. Thanks for the clarification.

He mentioned FFI into and out of his code, which has been my main encounter with unsafe rust too. Often enough I could limit the use to the entry/exit code but that's not always possible.

Anything where you are doing massive and complex parallelism will require tonne of unsafe. Think co-operative thread groups on 120x4 = 480 core machines.

Reply on news.ycombinator.com