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.

Navigating Feedback Loops – A Practical Approach

Mojo’s design—particularly its emphasis on ownership and concurrency—can lead to some very specific technical discussions. It’s not just about what you’re building; it’s how you communicate that build, particularly when receiving feedback. As a Mojo developer, you’ll spend a significant amount of time discussing the implications of your design choices through written communication – pull requests, code reviews, Slack threads, and documentation. Mastering this communication is crucial for collaboration and ensuring your work aligns with team goals. A common stumbling block for non-native English speakers is translating technical concepts into clear, precise language. It’s easy to fall back on overly formal phrasing or use jargon without fully explaining its context.

Let’s consider a scenario: you’ve submitted a pull request introducing a new SIMD vector operation. During the code review, a senior engineer leaves a comment stating, “This looks good in isolation, but I’m concerned about potential data races if this isn’t properly synchronized with the existing memory management system.” A simple, direct response might be, “I understand your concern regarding race conditions. I’ve added explicit locking around the SIMD operation to prevent concurrent access and ensure thread safety.” However, that’s a functional description; it doesn’t fully address why the lock was necessary or how you validated its effectiveness. A more robust response would be, “Thank you for flagging this – it’s a crucial consideration with SIMD operations. We’ve implemented mutexes to serialize access to the vector data, ensuring that only one thread can modify it at any given time. We’ve also added unit tests specifically targeting potential race conditions using ThreadSanitizer to confirm its effectiveness.” Notice the shift in tone – acknowledging the feedback, explaining the reasoning behind your solution, and demonstrating you’ve taken proactive steps to mitigate the risk.

Another common situation arises during PR descriptions. When proposing a change related to Python interoperability, clarity is paramount. A weak description might be: “Fixes Python interop issues.” A stronger one would elaborate, “This PR addresses intermittent failures when calling Python functions from Mojo due to type mismatches in the data structures. Specifically, we’ve implemented explicit casting using cast<py::object> where necessary to ensure compatibility between Mojo’s ownership model and Python’s dynamic typing. This resolves a reported bug [Issue #123] and includes improved logging for debugging future interop issues.” Detailed descriptions not only convey the technical details but also provide context, allowing reviewers to quickly understand the scope of the change and its potential impact.

Finally, remember that brevity is key, but don’t sacrifice clarity. Strive for concise language while fully articulating your reasoning and demonstrating a thorough understanding of the implications of your work.

// Example: Using ThreadSanitizer to detect race conditions in Mojo code
#include <thread>
#include <vector>

int main() {
  std::vector<int> data(10);
  for (int i = 0; i < 10; ++i) {
    data[i] = i;
  }

  // Simulate a race condition using multiple threads
  std::thread t1([&]() {
    for (int i = 0; i < 5; ++i) {
      data[i] += 1;
    }
  });
  std::thread t2([&]() {
    for (int i = 5; i < 10; ++i) {
      data[i] += 1;
    }
  });

  t1.join();
  t2.join();

  // Run ThreadSanitizer to detect race conditions
  // This would typically be invoked via the command line:
  // threadsanitizer ./your_mojo_executable
}