The naive comparison ¶

Taking this surface view at face value, here is how the two projects look:

This table is not wrong. But it frames the comparison badly, and several of the entries deserve to be challenged.

SPy is not pure research ¶

The most important correction to the naive view is about SPy’s purpose. Antonio Cuni works full-time on SPy, funded by Anaconda. The goals listed in the Zen of SPy are concrete engineering goals:

1. Easy to use and implement. The language is easy to understand. Moreover, it must be possible to implement SPy without huge engineering teams.

This is not the language of academic research — it is the language of deliberate, practical engineering with real constraints. Anaconda is not funding SPy purely for intellectual interest. The practical vision is a language that can be used alongside Python in the scientific and data ecosystem — the same ecosystem Anaconda serves.

Two independent languages, two different relationships with Python ¶

This is the subtlest point in the comparison, and the one most easily flattened by a quick reading.

Both SPy and Mojo are genuinely independent languages — neither is Python, and both can produce standalone binaries that carry no Python dependency at runtime. The SPy AWS Lambda demo is an instructive example: a SPy function compiled to a self-contained native binary and deployed as an AWS Lambda custom runtime, with no CPython interpreter involved whatsoever. The cold start time of such a binary is dramatically better than a Python Lambda — no interpreter to initialise, no packages to import, just a small native executable. This is a deployment mode that has nothing to do with Python at all.

Mojo is equally capable of standing alone. It can produce fully native binaries, and its systems-programming features (ownership, struct , manual memory management) are designed precisely for code that never touches a Python runtime.

So the distinction is not “companion vs. independent.” Both languages sit on a spectrum, and both occupy multiple points on it simultaneously. The real difference is in where the centre of gravity lies — what the language is primarily optimised for, and what relationship with Python feels most natural to its users.

SPy’s centre of gravity is close to Python. Cuni states it clearly:

SPy still aims to have a very tight integration with the existing Python ecosystem. It is possible to import Python libraries from SPy, and SPy modules from Python.

The .spy file extension is a deliberate signal. The design goals — easy to learn for Python users, bidirectional import, tight ecosystem integration — all point toward SPy being most at home as a sibling language. Think of it as what Cython or RPython aspired to be: a way for Python library authors to write high-performance code that their Python users can consume naturally, without learning a new paradigm. The standalone binary mode is a genuine and useful capability, but it is not the primary story.

Mojo’s centre of gravity is further from Python. It introduces ownership, borrow checking, struct vs class , fn vs def , and other concepts from Rust and C++ that are foreign to Python developers. Its aspiration to become a Python superset is real, but its design is shaped more by the needs of systems and GPU programming than by the needs of Python library authors. Mojo can call Python packages and produce Python extensions, but the learning investment required pushes it toward being used as a primary language rather than as a complement.

This is not a value judgement — it is a difference in orientation that leads to different strengths and different natural audiences.

Mojo’s “superset” claim deserves scepticism ¶

Cuni addresses this directly, though without naming Mojo:

The myth of 100% compatibility — the vast majority of “compilers for Python” which exist or existed in the past are not 100% compatible. They don’t support the full language even when they claim so. SPy prefers to be more explicit and honest about it.

Full Python compatibility in a compiled language would require supporting __class__ reassignment, metaclass magic, dynamic module mutation at runtime, the full CPython C API, and dozens of other features that are essentially incompatible with ahead-of-time compilation. The practical subset of Python that Mojo will realistically support is likely to be similar in scope to what SPy targets — SPy is simply honest about this from the start.

This is not a criticism of Mojo as such. It is a criticism of the framing. In practice, neither language needs to be a true superset to be extremely useful.

SPy will feel closer to Python for most Python users ¶

Mojo introduces struct , fn , var , let , ownership semantics, and borrow checking — concepts borrowed from Rust and C++ that most Python developers have never encountered. The learning curve is steep even when the syntax looks familiar.

SPy’s ambition is different:

I expect that for a large fraction of Python users, it will not matter [that SPy is not Python]. There are many users who mainly consume complex libraries written by others and write “straightforward” Python code: for them, writing SPy should be as easy as writing Python.

The features that SPy removes are the obscure corners of Python — the dynamic dispatch machinery that most Python users never consciously rely on. The features it adds (static typing, zero-cost abstractions, rich metaprogramming) are things that good Python programmers already reach for via type hints, dataclasses, and decorators. For this audience, SPy should feel like a natural step, not a new language.

Simplicity as a design constraint ¶

Mojo is backed by a large engineering team at Modular. The Modular platform has hundreds of thousands of lines of open-source code and thousands of contributors. This is a well-resourced product effort.

SPy’s first design goal is explicitly the opposite:

It must be possible to implement SPy without huge engineering teams.

This constraint shapes the entire language. Features that would require enormous compiler infrastructure are excluded or deferred. This is not a weakness — it is a deliberate bet that a simpler, more auditable language with a smaller implementation is more sustainable and more trustworthy for library authors who need to understand what is happening under the hood.

SPy as a better RPython ¶

This angle is almost entirely absent from the naive comparison, yet it may be one of SPy’s most interesting long-term possibilities.

RPython is the restricted Python-like language in which PyPy itself is written. It is a statically compilable subset of Python used to implement high-performance interpreters and runtimes. Antonio Cuni is a PyPy core developer — he knows RPython’s strengths and limitations intimately.

SPy can be seen as the next iteration of that idea: a clean, statically compilable Python variant (not just a subset — it adds new features that RPython lacks) that could be used to implement interpreters, language runtimes, and other systems-level tools. Mojo has zero interest in this space. If SPy matures in this direction, it would fill a gap that nothing else currently fills well.