
\documentclass[10pt]{beamer}

\usetheme[font=helvetica]{TUW}

\title{Rust Design Principles}
\author{Florian Sextl \and Mark Chimes \and Adrian Rebola-Pardo}
\date{2025-03-25}

\begin{document}

\begin{frame}
\titlepage
\end{frame}

\begin{frame}{Rust in a nutshell}
    Rust is a systems programming language.
    \begin{itemize}
        \item fine-grained control of memory and resources
        \item high-level abstractions to do so
        \item abstractions with different cost structures (including zero-cost)
    \end{itemize}

    Yes, Rust has pointers. But you will \textit{actively avoid} using them.\\
    {\small\url{https://doc.rust-lang.org/std/primitive.pointer.html\#method.add-1}}

    Custom allocation is \textit{still} experimental!\\
    {\small\url{https://doc.rust-lang.org/std/alloc/trait.Allocator.html}}
\end{frame}

\begin{frame}{The goals of Rust}
    At this point a meme: \emph{blazingly fast}

    Full resource control behind locked-down interfaces.

    Highly long-term maintainable code, at the expense of short-term development time.

    Well-designed APIs do not need the developer to mind the gap;
    \emph{memory safety} as the ultimate gap.

    Extensive \textit{and} extensible ecosystem (Cargo, rustdoc).
\end{frame}

\begin{frame}{Buzzwords for Rust}
Buzzwords that apply to Rust
\begin{itemize}
    \item \emph{Procedural}: explicit control flow
    \item \emph{Statically typed}: with generics but not dependent types
    \item \emph{Concurrent}: async in the type system, futures/atomics through std
    \item \emph{RAII}: low-key the cornerstone of Rust
\end{itemize}

Buzzwords that only sort of apply to Rust
\begin{itemize}
    \item \emph{Declarative}: only for type bounds (but strongly so)
    \item \emph{Functional}: strong use of closures, unique function typing,
    function ``types'' as interfaces
    \item \emph{Metaprogramming}: generics implemented through templates,
    but modeled through constraint problems
\end{itemize}
\end{frame}

\begin{frame}{Rust is data-oriented}
Rust follows the RAII paradigm:
\begin{itemize}
    \item No constructors: any function returning a value is responsible for resource allocation
    \item Visibility control enforces correct resource allocation
    \item Everything is an ``object'': privileged traits control byte-clone correctness (Copy)
    and resource deallocation (Drop).
    \item Types have associated methods.
    \item Traits (interfaces) control specialization.
\end{itemize}

In Rust there are no ``objects'', there are only values.
\end{frame}

\begin{frame}{Rust is not object-oriented}
Rust is not OO, with full intent:
\begin{itemize}
    \item Associated methods are just functions.
    \item No inheritance, no subclassing: interface relations expressed through bounds.
    \item The diamond problem is a compile error.
    \item Dynamic dispatch imposes additional restrictions on traits.
\end{itemize}

OO: types are data and the methods that operate on it.

Rust: types are \emph{control over} data and \emph{invariants} over the methods that operate on it.
\end{frame}

\begin{frame}{Ownership}
    A value \emph{recursively owns} resources: those resources can only be accessed by borrowing from the value.
    \begin{itemize}
        \item \emph{Shared borrowing}: several immutable borrows are simultaneously possible
        \item \emph{Mutable borrowing}: a unique mutable borrow is simultaneously possible
        \item \emph{The golden rule of Rust}: shared XOR mutable (else a compile-time error)
        \item \emph{Not so obvious conclusion}: borrowing \textit{is a resource}.
    \end{itemize}
\end{frame}

\begin{frame}{Spicy pass-by-value}
    Rust values free their allocated resources when they go out of scope.

    Rust arguments are \textit{always} pass-by-value (so they go out of scope at return).

    References are values that own borrows for a given \emph{lifetime}:
    \begin{itemize}
        \item \texttt{\&'a T}: immutable borrow of a \texttt{T} value for lifetime \texttt{'a}
        \item \texttt{\&'a mut T}: mutable borrow of a \texttt{T} value for lifetime \texttt{'a}
    \end{itemize}

    \emph{Your task as a Rust programmer}: convincing the borrow checker that the way you are accessing
    data does indeed agree with \emph{shared XOR mutable}.
\end{frame}

\begin{frame}{Safe vs unsafe Rust}
\emph{Your task as a Rust programmer}: convincing the borrow checker that the way you are accessing
data does indeed agree with \emph{shared XOR mutable}

The borrow checker is overprotective: sometimes what you want to do is \emph{sound} (respects the borrow rules)
but \emph{unsafe} (cannot be guaranteed by the compiler)

\emph{An escape hatch}: \texttt{unsafe} blocks allow the developer to avoid compiler oversight
(but \emph{absolutely not} the borrow rules).
\end{frame}

\begin{frame}{Zero-cost abstractions}
Rust encourages composition to enforce invariants.

\emph{Typical case}: your type is a tower of wrappers, each enforcing a stronger invariant

\emph{Zero-cost abstraction}
\begin{itemize}
\item Memory layout and internal representation are (mostly) handled by the compiler
\item Simple call-passing is often compiled away
\item Simple generics and trait-based implementations often compile away into mere control flow (e.g. iterators)
\end{itemize}
\end{frame}
\end{document}