English for Mojo Developers

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.

Navigating Feedback Loops – Beyond “Fix This”

Mojo’s focus on building high-performance, MLIR-backed systems means conversations around code quality and optimization are critical. Simply telling someone to “fix this” isn’t sufficient. The goal is to elicit a response that demonstrates understanding of the underlying technical challenges, potential trade-offs, and proposed solutions – all communicated clearly in English. A common frustration for non-native speakers is feeling like their contributions aren’t being fully appreciated because feedback lacks context or detail. It’s not about blame; it’s about collaborative improvement.

Consider a scenario: Sarah, a junior developer, submits a PR containing an optimization she believes will improve model latency. The lead engineer, David, leaves a comment that reads “This needs work.” While technically accurate, it provides zero actionable information. Sarah might feel discouraged and unsure of how to proceed. Instead, David should aim for something like: “The changes to the compute_matrix_multiply kernel show promise in reducing latency, particularly with the vectorization we’ve added. However, I’m concerned about potential memory usage spikes during larger matrix operations – could you investigate adding a caching mechanism or profiling this section under different load conditions? Let’s discuss your reasoning and explore alternative approaches if necessary.” Notice how David frames it as an opportunity to learn and refine the optimization, offering specific suggestions for further investigation. The key is shifting from a directive (“fix this”) to a collaborative request for understanding.

Furthermore, precise terminology becomes incredibly important when discussing MLIR transformations and performance. Using phrases like “improve throughput” versus “reduce latency” has different connotations and implies distinct optimization strategies. Similarly, conversations about struct ownership and memory management require clear articulation of concepts like “borrowing” and “lifetimes.” Don’t assume familiarity with these terms – always clarify them within the context of the discussion. Focus on why something is being done, not just what is being done.

Here’s a simple example using mlir for demonstrating this:

# This demonstrates a basic MLIR transformation to specialize
# a matrix multiply kernel based on input dimensions.
use ::.MatMulOp;
use ::.AffineMap;
use ::.IntrinsicExpr;

let input_size = 16; // Example size, could be dynamic
let output_size = 32;
let map = AffineMap::create(input_size, output_size);  // Create a linear mapping
let specialized_kernel = IntrinsicExpr::create(map, MatMulOp::kTilingSize);

// This is a simplified representation - actual MLIR code would be much more complex.

Remember, effective communication isn’t just about using the right vocabulary; it’s about fostering a culture of constructive feedback and shared understanding within your team – one where nuanced technical discussions are encouraged and valued.