Revisiting Mojo: A faster Python?

When the Mojo language first appeared, it was promoted as being the best of two worlds, bringing the ease of use and clear syntax of Python, along with the speed and memory safety of Rust.

For some time, the only way to evaluate those claims was using an online notebook environment that ran Mojo code on remote servers. More recently, the Mojo compiler has been released as a standalone download for Mac and Linux. (Microsoft Windows is not yet supported directly, but it’s possible to run Mojo by way of WSL2.)

In this article, we’ll look at what it’s like to use Mojo locally. We’ll also discuss how Mojo resembles Python, how it’s different, and what it has to offer to programmers familiar with Python and other languages.

Mojo language basics

When Mojo was first announced, it was easy to think of it as a “superset” of Python, where existing Python programs would also be valid Mojo programs. It has since become clear that Mojo’s goal is not to provide inherent compatibility with Python—that is, it isn’t meant to be a runtime for existing Python programs. Instead, Mojo aims to provide a syntax that’s familiar and comfortable to Python users, but a feature set that’s more suited to lower-level programming than Python—for instance, to allow manual memory management in the style of Rust or C++.

Where full compatibility with Python programs and the Python ecosystem is required, Mojo can call out to the Python runtime and use it to handle those cases. The disadvantage there is performance, since calls to the Python runtime and anything in its sphere incur a cost. As a workaround, you could use Python in cases where you needed its ecosystem, and Mojo where your priority was performance.

Mojo’s most touted advantage over Python is that it is compiled ahead of time to machine-native code, using the LLVM toolchain. This gives Mojo programs an inherent speed advantage, although that advantage holds up best when working with features specific to Mojo.

Python features are likely to come at the cost of emulating Python’s dynamic behaviors, which are inherently slow—or again, by just using the Python runtime. That said, Mojo has native behaviors that can replace some of those things. For instance, in lieu of Python’s non-native integers of any size, Mojo can support integers of up to 256 bits that are actually aliases for fast SIMD operations.

Comparing syntax: Mojo vs. Python

Many of Mojo’s native language features do one of two things: They’re either entirely new features not found in Python or a more performant expansion of a Python feature. In the latter case, enhanced performance comes at the cost of losing Python’s dynamism.

In Python, for instance, there is no way to formally declare variable references; variables are just created as needed. In Mojo, you can use the keyword var to make an explicit variable declaration in the current scope. How the two languages handle variable scoping is also different. In Mojo, a variable can only be scoped within a given nested code block, such as an if block  (although you can pre-declare variables in the larger scope). In Python, a variable declared in an if block persists after the block ends.

Mojo also has its own struct keyword that stands in contrast to Python’s class. Classes are just Python classes, with all the dynamic (and slow) behaviors you’d expect. The struct types, though, are more like their C/C++ and Rust counterparts, with fixed layouts determined at compile time but optimized for machine-native speed.

Another Mojo keyword designed to distinguish Mojo’s behaviors from Python’s is fn. You can use def or fn to define a function, but fn will only allow you to raise errors when they are explicitly defined. Typically, a fn function handles all its own error conditions internally. This avoids generating potentially unneeded runtime error-handling code, which could impact performance.

The following code snippet, a struct for a point-like entity, shows all these principles in action:

struct Point:
var x: Int
var y: Int

fn __init__(out self, x: Int, y: Int)
self.x = x
self.y = y

As a Python developer, you’ll notice immediately how closely Mojo code resembles Python’s—the use of whitespace for syntax, for instance. But the differences add up.

The Mojo compiler and toolchain

If you want to use Mojo on your own system, Modular provides downloadable binaries. If you’re already a Python user, the easiest way to get started with Mojo is to set up a Python virtual environment and install Mojo as if it were a Python package. This also makes cross-integration with Python easier, as any third-party Python libraries needed for a Mojo project can be installed and used in that venv. (More on this later.)

Once you have it set up, running Mojo programs is as simple as writing a file with a.mojo extension and using mojo filename.mojo to run it. The startup time for a Mojo program is noticeably longer than for a comparable Python program; that’s because the Mojo program is compiled to native code. If you use mojo build filename.mojo, that compiles the program in question to a standalone binary, and lets you reuse it without having to recompile. Compiled Mojo binaries can be quite compact; a simple “Hello, World!” program compiles to a 19K binary on Linux.

The Mojo toolchain can also be used with Modular’s package manager and project management tool, pixi. You can use pixi to manage Mojo-only projects as well as projects that blend Mojo and Python, as it supports all the metadata used in Python projects (e.g., pyproject.toml). The tool also provides lockfile and environment-management mechanisms. Some of the demo projects in the Mojo repository use pixi, but it’s entirely possible to keep using pip or uv if you’ve already invested in those tools.

Working with Python in Mojo

When you write Mojo code, the default assumption is that everything you type is Mojo. If you want to use Python features, you have to import them specifically. For instance, if you wanted to use NumPy from Python to do something specific to it (like integrating it with an existing workflow), you’d do something like this:

from python import Python

def main():
np = Python.import_module('numpy')
rand_array = np.random.rand(32)

The Mojo module python provides interop with the Python ecosystem as a whole, and the Python.import_module method works like Python’s own import mechanism. Every standard library item in Python, along with every third-party module installed into the virtual environment you’re using, can be imported this way. Imports do have some restrictions—you can’t import into the top level of a Mojo module, and you can’t emulate from x import y behaviors yet.

What’s key about Python/Mojo interop is that all native Python operations use an instance of the Python runtime. They aren’t emulated in Mojo itself. The advantage here is all Python behaviors are exactly what you’d expect them to be. But the downside is that every call across the Mojo/Python boundary incurs a performance cost. This isn’t peculiar to Mojo; any interop between Python and another language through Python’s foreign function interface sustains a per-call overhead. The common way to handle this is just to reduce the number of calls in either direction, by batching operations.

Mojo can also be called from Python in cases where you run Python programs in the same environment as Mojo. The mechanism for doing this is more complex, though, and requires some boilerplate. But the end result allows Python to see and use Mojo modules as Python extension modules, as if they were written in C or Rust, or by way of Python’s Cython project.

Could Mojo replace Python?

Mojo was originally touted as a language for data science and machine learning, but that pitch has since been refined. The About Mojo section of the language’s manual describes Mojo as “a systems programming language specifically designed for high-performance AI infrastructure and heterogeneous hardware.” Python, by contrast, is not intended to be a systems language, but has made a place for itself in the AI/ML world as a “glue language,” providing a convenient interface to things that by themselves aren’t convenient.

Replacing Python isn’t simply a matter of creating a faster language, because speed of execution was never Python’s draw to begin with. Speed of development and a robust ecosystem have always come first. For Mojo to replace Python, it would need to not only compete but excel in both of those categories. It would need to not just make use of existing Python libraries—since that comes at a potential performance cost—but create its own native equivalents for them. The same goes for having Mojo eclipse Python generally, such as in web development. Everything required to do that would take years to set in motion.

In the long run, Mojo is likely to be best used in the same way other languages are, as a complement to Python, enabling certain things that are still difficult to do in Python. In the meantime, Mojo can continue to grow on its own, and will eventually find a niche of its own.