Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> It's really only encapsulated in the sense that if you have a finite and small set of unsafe blocks, you can audit them easier and be pretty sure that your memory safety bugs are in there. This reality really doesn't exist much anymore because of how much unsafe is often ued, and since you you have to audit all of them, whether they come from a library or not, it's not as useful to claim encapsulation as one thinks.

Is it? I've written hundreds of thousands of lines of production Rust, and I've only sparingly used unsafe. It's more common in some domains than others, but the observed trend I've seen is for people to aggressively encapsulate unsafe code.

Unsafe Rust is quite difficult to write correctly. (The &mut provenance rules are a bit scary!) But once a safe abstraction has been built around it and the unsafe code has passed Miri, in practice I've seen people be able to not worry about it any more.

By the way I maintain cargo-nextest, and we've added support for Miri to make its runs many times faster [1]. So I'm doing my part here!

[1] https://nexte.st/docs/integrations/miri/



> and we've added support for Miri to make its runs many times faster

Whoa. This might be the kick in the ass I needed to give cargo-nextest a whirl in my projects. Miri being slow is the single biggest annoyance I have with it!


Would love to hear how it goes! Miri is generally single-threaded, but because nextest is process-per-test, each test gets a completely separate Miri context. A few projects have switched their Miri runs over to nextest and are seeing dramatic improvements in CI times, e.g. [1].

[1] https://bsky.app/profile/lukaswirth.bsky.social/post/3lkg2sl...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: