English for Mojo Language Developers

Mojo sits deliberately between Python and systems languages, so discussions about it often need to specify which “mode” a piece of code is in — Python-compatible dynamic code, or Mojo’s stricter, compiled, ownership-checked code — before the rest of the conversation makes sense.

Key Vocabulary

fn vs. def — fn declares a strict, statically-typed function that enforces argument types and ownership, while def declares a Python-compatible function with dynamic typing. “We rewrote the hot inner loop as an fn function so the compiler could catch the type mismatch that def was silently allowing.”

Ownership (owned, borrowed, inout) — Mojo’s system for tracking who controls a value’s memory, similar in spirit to Rust, specifying whether a function takes, reads, or mutates a value. “The function only needed to read the array, so we marked the parameter borrowed instead of owned — it avoided an unnecessary copy.”

Struct — a value type with a fixed, compiler-known layout, used for performance-critical data instead of a Python-style dynamic class. “We moved this from a Python class to a Mojo struct because we needed a guaranteed memory layout for the SIMD operations downstream.”

SIMD type — a built-in vectorized numeric type that lets a single operation apply across multiple values at once, central to Mojo’s performance story. “Switching the inner loop to operate on a SIMD[DType.float32, 8] vector instead of scalar floats gave us the speedup we were chasing.”

Python interop — Mojo’s ability to import and call existing Python modules directly, letting teams migrate incrementally rather than rewriting everything at once. “We’re not rewriting the whole data pipeline in Mojo — we’re using Python interop to keep the existing NumPy preprocessing and only rewriting the bottleneck in native Mojo.”

Common Phrases

• “Is this function fn or def — does it need strict typing, or is dynamic behavior intentional here?”
• “Should this parameter be borrowed instead of owned, since we’re only reading it?”
• “Is this a struct because we need a fixed memory layout, or would a regular value work fine?”
• “Are we using a SIMD type here, or is this still scalar and leaving performance on the table?”
• “Can we lean on Python interop for this part, or does it need to be native Mojo for speed?”

Example Sentences

Explaining an ownership choice in review: “I changed this parameter to inout because the function needs to mutate the buffer in place, not just read from it.”

Describing a migration strategy: “We’re keeping the orchestration logic in Python and only porting the numerical kernel to Mojo, using interop to glue the two together.”

Justifying a performance decision: “Switching from a Python class to a Mojo struct with a fixed layout let the compiler vectorize the loop automatically.”

Professional Tips

• State whether code is fn or def explicitly when discussing a type error — it changes what the compiler is allowed to assume.
• Name the exact ownership annotation (owned, borrowed, inout) when reviewing a function signature — it communicates intent that “takes a value” doesn’t.
• Justify a struct over a Python class by naming the specific performance or layout requirement, not just “it’s faster.”
• Frame Python interop as an incremental migration strategy in proposals — it reduces the perceived risk of adopting a newer language.

Practice Exercise

1. Explain the difference between fn and def in Mojo.
2. Describe when you’d choose borrowed over owned for a function parameter.
3. Write a sentence justifying an incremental migration using Python interop.