  The Rust programming language is an increasingly popular choice for systems
programming, since it can statically guarantee memory safety without automatic
garbage collection. Rust provides its safety guarantees by restricting aliasing
and mutability, but many key design patterns, such as cyclic aliasing and
multi-language interoperation, must bypass these restrictions. Rust's
$\texttt{unsafe}$ keyword enables features that developers can use to implement
these patterns, and the Rust ecosystem includes useful tools for validating
whether $\texttt{unsafe}$ code is used correctly. However, it is unclear if
these tools are adequate for all use cases. To understand developers' needs, we
conducted a mixed-methods study consisting of semi-structured interviews
followed by a survey. We interviewed 19 Rust developers and surveyed 160
developers$\unicode{x2013}$all of whom engaged with $\texttt{unsafe}$ code. We
found that 77% of survey respondents and a majority of interview participants
were motivated to use $\texttt{unsafe}$ code because they were unaware of a
safe alternative. Developers typically followed best-practices such as
minimizing and localizing their use of $\texttt{unsafe}$ code, but only 23%
were always certain that their encapsulations were sound. Limited tooling
support for inline assembly and foreign function calls prevented developers
from validating $\texttt{unsafe}$ code, and differences between Rust and other
languages made foreign functions difficult to encapsulate. Verification tools
were underused, and developers rarely audited their dependencies. Our results
indicate a pressing need for production-ready tools that can validate the most
frequently used $\texttt{unsafe}$ features.
