Memory Safe Language

A system where every value has exactly one owner at a time, and the compiler statically tracks ownership transfers. When the owner goes out of scope, the memory is automatically freed.

• Eliminates use-after-free bugs entirely
• Prevents double-free vulnerabilities
• No garbage collector overhead or pause times
• Example: Rust's borrow checker enforces ownership rules before the binary is ever produced

A compile-time mechanism that enforces strict rules about references to data: you can have one mutable reference OR multiple immutable references, but never both simultaneously.

• Prevents data races in concurrent code
• Eliminates dangling pointers by tracking reference lifetimes
• Catches iterator invalidation bugs at build time
• The compiler rejects code that violates borrowing rules, forcing correct memory management

Memory is freed deterministically when variables go out of scope, using RAII (Resource Acquisition Is Initialization) patterns. No manual free() or delete calls required.

• Prevents memory leaks from forgotten deallocations
• Eliminates use-after-free by tying resource lifetimes to scope
• Applies to files, sockets, and locks—not just heap memory
• Contrast with C's malloc/free where the programmer bears full responsibility

Array and vector accesses are automatically bounds-checked at runtime, with a defined panic rather than undefined behavior on out-of-bounds access.

• Prevents buffer overflow exploits that enable arbitrary code execution
• Eliminates heartbleed-class vulnerabilities
• Compiler optimizations remove checks when bounds are provably safe
• Optional unsafe blocks allow raw pointer access when performance demands it

A rich algebraic type system with Option and Result types forces explicit handling of null and error cases, making failure modes visible in the function signature.

• No null pointer dereferences—Option<T> requires pattern matching
• Result<T, E>` makes error propagation explicit and checked
• Pattern matching exhaustiveness checks prevent missed cases
• Sum types (enums with data) model state machines safely

Operations that bypass safety guarantees are confined to explicitly marked unsafe blocks, making dangerous code auditable and greppable.

• Raw pointer dereferencing requires unsafe annotation
• Foreign function interface calls are isolated in unsafe blocks
• Code review focuses on the small surface area of unsafe code
• Safe abstractions wrap unsafe implementations, containing risk