Warnings: still closed-source and very young ¶

Before delving into discussions about programming languages and Mojo, two crucial aspects merit attention.

Firstly, it’s essential to note that Mojo is currently a closed-source project under the guidance of the Modular company. Their goal is to monetize artificial intelligence (AI) by significantly enhancing the technological framework in this domain. The building blocks of this strategy are (i) a new AI Engine called MAX (something like TensorFlow and PyTorch, but somehow compatible with these solutions) and (ii) a new programming language — Mojo. While Modular asserts that Mojo is not intended to be a commercial “product” and write that they “expect to open-source Mojo progressively over time as it continues to mature” [ 1 ] , the project remains closed-source at present. This critical aspect will be revisited in more detail later.

Secondly, it’s important to acknowledge that Mojo is still in its early stages and, in my opinion, not yet ready for being used outside of Modular. The creators of Mojo focussed on the core of the language and on performance.

Building a new programming language ¶

While old programming languages like Python, C, C++, Java or Javascript, continue to dominate the landscape [ 2 ] [ 3 ] , the field of applied research in programming languages has witnessed remarkable activity in recent years. A wave of innovation has given rise to the introduction of new programming languages (to name a few, Zig, Vlang, etc.). Besides these veterans and newcomers, there are also few grown up languages (as Go, Rust, Julia and Swift) which gathered active communities around them.

In this note, the focus will predominantly be on Rust, Julia, and Swift. Rust, backed by the Mozilla Foundation, originated in 2006 and was publicly introduced in 2010, bringing noteworthy innovations compared to C++, particularly about safety with its borrow checker. This systems language has garnered success and found numerous applications, such as being employed in the development of Firefox. Despite its nice qualities, Rust is known for its steep learning curve, potentially making it less suitable for rapid prototyping in the scientific field. Julia’s development commenced in 2009, with the language officially launched in 2012 — over a decade ago. Over the years, Julia has matured and found its niche in intensive numerical computing applications, where it excels. Swift, Apple’s latest language, began development in 2010, with the first version released in 2014. Swift transitioned to an open-source model in 2015.

Starting a new programming language in 2023 is kind of a bold idea. In a landscape dominated by robust and mature choices, the competition among programming languages is formidable. A new language not only needs to introduce novel features and advantages over its direct competitors but also must be sufficiently good in various other aspects. The benefits of adopting the new language should outweigh the costs associated with using less the established language. Moreover, in this field, practicality often beats purity. The case of Julia versus Python is very interesting. Julia has clear advantages compared to Python for the field of scientific computing, in particular better performance and foundation, avoiding the “two languages problem”. However, Python is good enough, has other advantages and is evolving fast enough so that there is no significant shift towards Julia [ 4 ] .

Creating and establishing a new programming language is a monumental task. While considerable resources are naturally allocated to designing the language and developing its interpreter/compiler, one also need to consider other aspects including community building, tools for developers, packaging, libraries, documentation, etc.

Let us also note that language creation, building and evolutions are slow processes. These human constructs are so complex that the typical time scale is more years than months. In the cases of Rust, Julia, or Swift, several years elapsed between the initiation of the projects and their first public releases. The Mojo team, however, opted for an early release strategy, initiating their project’s public presence swiftly. Despite this, they are still in a fast and closed-source development mode with a small and coherent team. The impressive progress achieved in just over a year sparks curiosity about the future trajectory of the project.

Why Mojo can be successful ¶

Why should we care about this just born fancy programming language? In my humble opinion, compelling reasons suggest Mojo could emerge as one of the prominent languages in the coming years:

• Mojo is an answer to a real suboptimal state for computing (scientific and AI) dominated by languages with clear weaknesses (of course Python and C++, but also Julia and Rust). It would be a net improvement to have a new language with a better equilibrium between usability/performance/safety, with JIT/OAT compilation capacities and a nice learning curve, especially for individuals familiar with Python.

• Mojo is grounded in a great intuition: a static, safe language with strong dynamic capacities and seamless integration with Python.

• Mojo is led by very smart and renowned people, in particular Christ Lattner , the “co-founder of LLVM, Clang compiler, MLIR compiler infrastructure and the Swift programming language” (taken from his Wikipedia page). His impressive track record in successful and significant open-source projects adds a substantial layer of credibility. While other accomplished individuals contribute to Mojo’s creation, Chris Lattner’s remarkable CV stands out.

• Mojo has very solid technical underpinnings, LLVM and MLIR, as later discussed. “Mojo is the first major language designed expressly for MLIR” [ 5 ] .

• Mojo seems to have a solid and long term founding, backed by a serious company, with partnerships with Amazon Web Services (AWS) and NVidia .

The motivations driving the creation of Mojo are described in particular in the Why Mojo page . It is a lot about fixing the technological stack used in AI, dominated in particular by Python and C++. This positions Mojo as a fresh attempt to resolve the longstanding “two languages problem”, a challenge that has also been a primary focus for Julia. However, the approaches taken by Julia and Mojo to tackle this issue differ significantly, both in terms of technological essence (to be discussed later) and in their relationship with Python. In a somewhat provocative manner, Julia and its community are perceived as being “against Python”, while Mojo aims to become a new member of the Python family.

When Julia was conceived in 2009, Python’s footprint in scientific computing was relatively modest. Numpy was only introduced in 2006, and Python 2.7 wasn’t released until 2010. During this period, Matlab held a more dominant position. Consequently, the design of Julia leaned towards Matlab rather than aligning closely with Python-Numpy. Moreover, it is not convenient to use Julia to build packages usable from Python (or R by the way). The “one language for everything” approach is not very cooperative by nature. In contrast, the pragmatic strategy of employing distinct languages for different tasks has proven highly effective in constructing a robust scientific Python ecosystem. This ecosystem leverages languages such as C, Fortran, C++, and now Rust [ 6 ] in the background.

While Julia is great and has a great ecosystem in its niche — intensive numerical computing — it tends to be somewhat isolated. For the vast community of Python users and developers of Python packages, it is not so appealing to invest time on Julia.

Mojo’s alternative strategy about its relationship with Python appears quite reasonable. Introducing a companion and complementary language could find a warm reception within the Python community. Given the current dominance and momentum of Python (see the next section), as well as the inherent inertia in language dynamics, it is a very serious advantage for Mojo for the next decade.

Projects about extending what is possible with Python ¶

To better understand Mojo, it’s beneficial to clarify what it is not, by exploring a few projects aimed at enhancing Python and addressing its weaknesses.

• PyPy and GraalPy : These projects are faster alternative implementations of Python. However, their adoption is limited because they face challenges in accelerating packages that rely on the CPython C API, such as Numpy, Matplotlib, Pandas, scikit-learn, and others.

• Fixing the Python C API : Efforts are underway to resolve this limitation and enhance the usability of alternative Python implementations. These include the introduction of the new HPy C API and a more ambitious, long-term initiative aimed at improving the CPython C API .

• CPython Core Developments : The CPython core developers are actively engaged in initiatives to enhance the performance of CPython through projects such as no-gil, subinterpreters , and Faster CPython. CPython 3.13, which will be usable at the end of 2024, should have the GIL removed and a JIT compiler based on the Copy & Patch approach .

• Python compilers : Various Python compilers, such as Pythran, Numba, and Mypyc, have been developed to accelerate specific (static) subsets of Python, with some extending support to Numpy.

• GPU and parallel computing : Innovative projects like Codon and Taichi introduce Domain-Specific Languages (DSLs) within the Python environment, tailored for GPU and parallel computing.

Mojo distinguishes itself from these projects by being a truly independent language, rather than falling into the category of Python enhancements or alternative implementations.

Mojo==Python++? Actually something completely different ¶

Mojo website states that a long term goal of Mojo is to become a superset of Python , meaning that most Python programs should run without modifications. I’m not so optimistic about this but for me it is not so important. To run Python code, we anyway have other good Python interpreters. I consider that some Python features are not so useful for a project like Mojo, for example supporting the inspect module (for introspection), monkey patching of whatever (even the language builtins) or the CPython C API.

Anyway, it is important to realize that current Mojo is completely different from Python. There are few common builtin functions ( print , len , range , slice , …) and the syntax is largely compatible (imports, indexing, slicing, loops, function def, contexts, try/except, async/await, even struct definition with dunder methods, …). As already written, Mojo can also be “interpreted” and has a REPL (which can be started with the command mojo ). But some very important Python builtin types are missing (like str , int , float , list , tuple and dict ) and nearly no Python standard library is available. Moreover, more deeply and importantly, the semantic of the language is very different. For example, Mojo variables are much more like C variables than like Python variables: a name in Mojo is attached to an object. For example

from memory.unsafe import Pointer

def print_pointer(ptr: Pointer):
    print(ptr.__as_index())

def main():
    a = 1
    p1 = Pointer.address_of(a)
    print_pointer(p1)

    a = 2
    p2 = Pointer.address_of(a)
    print_pointer(p2)

    # a = "mojo"  # error: cannot implicitly convert 'StringLiteral' value to 'Int' in assignment

prints

140728977102328
140728977102328

meaning that there is only one integer variable which has been modified inplace with the statement a = 2 . In contrast, the equivalent Python code, something like,

a = 1
print(id(a))
a = 2
print(id(a))
a = "python"  # valid

prints

140163769254128
140163769254160

such that id(2) - id(1) is 32. The name (the reference) a first points towards the int object 1 . The statement a = 2 modifies the reference (the name a ) and not the integer object.

In Python, references are everywhere (the names are references, elements in a list/tuple are references, function arguments are passed as references). It does not work like that with Mojo, which has strong consequences. For example, in Python a = "py"; b = a creates two references pointing towards one object ( "py" ). In contrast, a = "mojo"; b = a creates two different objects at two different locations in the memory so that

b = "mojo"
p = Pointer.address_of(b)
print_pointer(p)

c = b  # <- this really copies the String object "mojo"
p = Pointer.address_of(c)
print_pointer(p)

prints something like

140720822767840
140720822767856

The contrast becomes evident in these examples as Mojo provides developers with a more direct engagement with objects in memory. Unlike Python and Julia, Mojo does not use reference counting and a garbage collector. Instead, memory management, defining the “lifetime” of objects, is automatically handled by a borrow checker, like in Rust. Nevertheless, Mojo also offers the flexibility to write code reminiscent of C, employing pointers and explicit allocation and deallocation of memory. In conclusion, it becomes apparent that Mojo is primarily a novel static language drawing inspiration from C++, Rust and Swift. This language is crafted for safe system programming.

def modify(a):
    # argument given by copy in Mojo `def` but one can modify the referenced list
    a[0] = 1

def main():
    a = object([0])
    b = a  # <- the reference is copied but not the pointed list

    print(a)  # prints [0]
    modify(a)
    print(a)  # prints [1]
    print(b)  # prints [1]

alias PI = 3.141592653589793
alias TAU = 2 * PI
alias my_alias = my_function_executed_at_compile_time()

fn bar[a: Int](b: Int):
    print("bar[a: Int](b: Int)")

@parameter
if ...:
    ...

@parameter
fn my_closure[size: Int]():
    ...

Comments on few current and future Mojo features ¶

from python import Python

np = Python.import_module("numpy")

What is missing in Mojo to be really usable for scientific computing? ¶

Conclusions ¶

As we’ve explored, one distinctive aspect of Mojo is its capacity to allow developers to write static, safe code akin to Rust. Simultaneously, Mojo supports dynamic code with the potential absence of typing annotations, similar to Python. While both aspects are still evolving and set to improve in the coming months/years, it’s crucial to recognize that even if Mojo aims to become a superset of Python, it should not be simply regarded as “Python++”. Instead, it is more accurate to view Mojo as a new, modern static language strongly influenced by C++, Rust and Swift, emphasizing performance, portability, and the ability to write generic code for exotic hardware. Only then can one appreciate that Mojo also offers interpretability with JIT compilation, features built-in capabilities for dynamically typed code, and the potential to become a quasi superset of Python.

We observe that Mojo shares similarities with and deviates significantly from Cython, a language that acts as a superset of Python with C capabilities. Unlike Mojo, Cython code necessitates transpilation to C and cannot operate independently of a Python interpreter. Cython is widely adopted in numerous successful packages within the numerical Python stack, such as scikit-learn. However, its usage remains confined to this specialized niche application. If it becomes possible to create Python extensions from Mojo code, a distinctive application for Mojo could be as a compelling alternative to Cython.

The current trajectory of Mojo suggests it is being crafted for long-term success. Modular envisions building a powerful programming language designed to thrive over the coming decades, positioning Mojo as a formidable contender against established, mature, and fully open-source languages. However, uncertainties surrounding the future licensing of the Mojo interpreter/compiler, particularly the potential retention of core components as closed-source, raise concerns about the compatibility of these ambitions.

The Mojo team is on track to deliver an exceptional language for high-performance computing in the next few months. Given the remarkable progress witnessed so far, it’s reasonable to anticipate that by the end of 2024, Mojo will be technically robust, featuring improved lifetime management, Rust-like Enum, Python compatibility, and more.

The pivotal decision about whether the core of Mojo becomes fully open-source holds significant consequences. If fully open-source, Mojo could have a transformative impact, especially within the Python community. This scenario would require investment from the Mojo team to enable the generation of Python extensions from Mojo code. The resulting open-source momentum could rapidly enhance the Mojo ecosystem, fostering the development of numerous new libraries. On the contrary, if the core of Mojo remains partly closed-source, adoption may be subdued, with many opting for alternative open-source solutions. It is noteworthy that when I introduced Mojo to experienced and highly qualified developers, the initial response often revolved around its closed-source status and the uncertainties regarding its future open-source status.

I tend to be optimistic about the future open-source nature of Mojo because this is in the interest of Mojo, and thereby of Modular. Mojo is still a growing baby bird in its closed-source nest. The hope is that, in the coming years, Mojo will spread its wings, soaring alongside its renowned open-source counterparts in the rising currents of collaborative development.

In conclusion, I would like to share my highly personal impression of Mojo. As a Python developer with experience in static languages and high performance computing, the experience of using and exploring Mojo has been both delightful and intellectually stimulating. It gives me a sense of being at home, on holiday, and having superpowers all at once. On the other hand, since it’s not easy to learn to drive with a space shuttle, it’s debatable whether Mojo should be put in everyone’s hands.