English for Mojo Developers

Master the English vocabulary Mojo developers use for ownership, structs, and MLIR-backed performance when discussing systems-level AI code with a team.

Mojo positions itself as “Python’s syntax with systems-level performance,” which means its English vocabulary borrows familiar Python words while attaching much stricter, Rust-like meanings around ownership and value semantics — a gap that trips up developers coming from pure Python. This guide covers the English used when discussing Mojo code with a team.

Key Vocabulary

Ownership — Mojo’s compile-time-tracked model of which variable is responsible for a value’s lifetime, determining when it’s copied, borrowed, or moved, similar in spirit to Rust’s ownership model. “This function takes the list by value instead of borrowing it — that forces an implicit copy on every call, which defeats the performance win we wanted from Mojo.”

Struct (vs. class) — a value-type data structure with static dispatch and no implicit inheritance, used for performance-critical code, contrasted with Mojo’s Python-compatible classes which retain dynamic, reference-type behavior. “Use a struct here, not a class — we need value semantics and static dispatch for this hot loop, and a class would add reference-counting overhead we don’t need.”

Borrowed / owned / inout — Mojo’s argument conventions specifying whether a function reads a value without taking ownership (borrowed), takes ownership (owned), or can mutate the caller’s value in place (inout). “Mark this parameter inout instead of owned — we want the function to mutate the caller’s buffer directly, not take ownership and hand back a new one.”

MLIR (Multi-Level Intermediate Representation) — the compiler infrastructure Mojo is built on, which lets it generate highly optimized code for different hardware targets, including CPUs and GPUs, from the same source. “The reason this loop vectorizes so well isn’t magic — it’s Mojo lowering to MLIR and letting the same optimization passes used for other hardware targets apply here too.”

SIMD type — a built-in vectorized type representing multiple scalar values processed in parallel by a single instruction, exposed directly in Mojo’s type system rather than hidden behind a library. “Instead of looping element by element, use a SIMD type here so the compiler can emit vectorized instructions directly instead of relying on auto-vectorization guesses.”

Zero-cost abstraction — a language feature (like Mojo’s structs or its ownership checks) that adds no runtime overhead compared to hand-written low-level code, with all the safety or ergonomics enforced at compile time. “The bounds checking here is a zero-cost abstraction — it’s fully validated at compile time, so there’s no runtime penalty compared to writing the unsafe raw-pointer version by hand.”

Common Phrases

  • “Is this parameter borrowed, owned, or inout — and does that match what the function actually needs to do?”
  • “Should this be a struct instead of a class, given we need value semantics here?”
  • “Is this loop using a SIMD type, or relying on the compiler to auto-vectorize?”
  • “Does this abstraction have any runtime cost, or is it fully resolved at compile time?”
  • “Is this copy implicit because of the ownership convention, or is it necessary?”

Example Sentences

Reviewing a pull request: “This function declares the buffer parameter as owned but never actually needs to keep it — switching to borrowed avoids an unnecessary copy on every call.”

Explaining a design decision: “We used a struct with inout methods for the matrix type instead of a class, so in-place mutation during the hot path doesn’t allocate or trigger reference counting.”

Describing a performance win: “Rewriting the inner loop with an explicit SIMD type instead of a scalar loop cut the runtime in half, because the compiler no longer had to guess whether vectorization was safe.”

Professional Tips

  • Say “borrowed,” “owned,” and “inout” explicitly when discussing function signatures — these are load-bearing keywords in Mojo, not stylistic choices.
  • When reviewing performance-sensitive code, ask “is this a struct or a class?” — the answer determines whether you’re getting value semantics and static dispatch or reference semantics with overhead.
  • Use “zero-cost abstraction” precisely — it means no runtime cost versus the hand-written low-level equivalent, not merely “efficient.”
  • Distinguish “SIMD type” (an explicit vectorized type in the type system) from “auto-vectorization” (the compiler inferring vectorization from a scalar loop) when discussing why a hot loop is fast or slow.

Practice Exercise

  1. Explain in two sentences why marking a parameter owned when borrowed would suffice can hurt performance.
  2. Write a one-sentence code review comment recommending a struct instead of a class for a performance-critical type.
  3. Describe, in your own words, what “zero-cost abstraction” means in the context of Mojo’s ownership checks.