Skip to content
Rust Search
← Browse conferences

A hammer you can only hold by the handle

Rust Programming Language
RustFest 16:07 1462 views

Rust’s type system provides tools to ensure safe memory management, and safe concurrent access to data. What if we used those same tools to encode and enforce other API constraints? We can leverage affine types (non-Clone structs) to enforce that a user performs a series of operations in a certain order; or we can use structs as tokens representing the user’s ability to perform certain actions. And everything’s checked at compile time. We’ll see how these techniques let us encode complex API c

Player unavailable or embedding blocked? Use the YouTube link above.

Other talks by Andrea Lattuada

Containing the RDMA plasma

FOSDEM

This talk is an experience report on my safe rust wrapper for a c++ RDMA library^1. RDMA enables the network hardware to directly read and write to memory, without the cpu's involvement. My rust implementation ensures that memory regions are exclusively either owned by client code, or enqueued for use by the underlying RDMA stack. This makes sure that data cannot be changed by hardware while owned by safe rust code, and that user logic cannot mutate data while it is being read by the card. In this talk, I'll go over the design of the library and how it embraces rust's ownership transfer semantics. In rust's safe/unsafe model, the burden of upholding safety guarantees at the unsafe boundary is entirely up to the programmer who's writing the wrappers. These guarantees are not formally specified, which makes it harder to reason about the safety of the wrapped unsafe logic; this issue is compounded by the fact that undefined behaviour can seep into safe rust from unsafe code that doesn't match rust's expected semantics. I'll discuss how this improves ergonomics in safe code, but requires careful engineering of unsafe code because it doesn't allow the programmer to reason locally.