As part of our ongoing evolution of Mojo, we’re officially deprecating REPL support.
Today, Mojo is an excellent language for GPU programming and high-performance computation, and we’re currently not prioritizing its use as a superset of Python. The REPL experience isn’t as beneficial for this new direction, so we’ve decided to sunset it.
Here’s what you need to know:
- The REPL is still available in nightly builds for now, but it will be removed in the upcoming 25.3 release. - As a result, docstring-based testing will no longer be supported. If you have Mojo code embedded in docstrings, that code will not be executed when running mojo test (since it was previously executed via the REPL). - The Mojo Jupyter kernel (which depends on the Mojo REPL) will also be deprecated in the 25.3 release. - You can still include embedded code in docstrings for illustrative purposes, but if you want it tested, please move it to example files or test files instead. Instead of running magic run mojo test, instead set up a dedicated testing environment and a test action with Magic and use magic run test. Please see the Mojo standard library test files and MAX examples for examples of how we recommend structuring tests.
Thank you for your understanding as we continue refining Mojo for high-performance computing.
Much of the discussion is speculation around what drove this change, I think that a lot of people would like to know the reason behind this removal, which comes as something of a surprise. @ahajha speculated it was maintenance costs and others have speculated it’s in preparation for doing a lot of work on Mojo.
A lot of users expressed concerns for use in data analytics and exploration, since notebooks tend to be nicer places to do that because you can more easily inspect the state of the program. One common way to deal with a lack of this is to serialize the state to disk and “cache” stages of a normal program, something Mojo is distinctly bad at currently. Mojo is also very good at data analytics since you can use straightforward code instead of needing to lean on libraries to handle trivial amounts of data, so a lot of people were excited about this use-case. What are the plans to serve this group of users? Will the REPL come back later, after Mojo has matured more? Will notebooks be implemented with the “serialize the state” method instead?
This has also invoked some discussion about making other changes, such as dropping def, which has odd interactions with the rest of the language given that the entire stdlib requires static types. Personally, I think that Object has also not exactly been the most “well loved” type in the stdlib, and it doesn’t have great support in a lot of places, I think in part because many of the external stdlib contributors (myself included) effectively ignore the existence of def and treat Mojo as a statically typed language.
Ping @clattner since he requested to move over to the forum and can help answer some of this.
I can give more color from my understanding on this, but I’ll let others make the call. I think it is less about Python or use-cases specifically, and more driven by internal technical debt and design issues, which have led to the REPL not getting the maintenance that it deserves.
Background: The Mojo REPL (like the Swift repl) is implemented using LLDB as a host. LLDB uses an LLVM codepath called the “MC JIT” to evaluate expressions and put them in the target process, the MC JIT is the “older” infrastructure in LLVM. Mojo bet early on the more modern path, the “ORC JIT” (mentioned in this tech talk) but LLDB doesn’t get along with the ORC JIT.
We’ve had these two paths going, but they cause a number of problems. In the last 6 months in particular, the mojo team has been doing a lot of work on improving code generation speed and all this complexity is just getting out of hand. We need to cut back some of the tech debt, get things simplified, then rebuild again.
My understanding was that the repl wasn’t widely used, but maybe that isn’t true. If you’re using it, can you share more of the things you find it useful for today? That will help us shape our priorities and figure out the right way to look at this.
To Alex’s point on the forum, as a general principle, I don’t like us having a bunch of appealing but half-baked capabilities. I think it is generally better to focus on “less stuff”, make sure it is good, and expand things out over time. I do think that it is important for Mojo to have a REPL, but it just seems premature.
How about def and Object as Owen mentioned? They seem also to be halve baked
Agree, I’d love to see Object just get reimplemented. I think these are very important and I wouldn’t advocate for them getting ripped out necessarily, I think they can be fixed in place. They are “local damage” :), not slowing down who scale system evolution.
What is the problem with def (besides defaulting to returning object)? THAT could definitely be changed, to default to returnning None for now.
Would it be reasonable to fix that? I’ve seen some blog posts in the Rust community discussing that a lot of LLDB is very C/C++ centric, which causes issues for Rust and I imagine would also cause Mojo some issues. A JIT which is designed to be more flexible, OrcJIT, might help those issues. I know that building a debugger is painful, so that is likely out of scope.
My understanding was that the repl wasn’t widely used, but maybe that isn’t true. If you’re using it, can you share more of the things you find it useful for today?
I would say that most of my “repl-like” work takes place in a “scratch.mojo” file I keep in my version of the stdlib repo. Part of this is because I run into ICEs with some frequency, which makes using a REPL painful. When I do use the REPL, it’s mostly to quickly confirm bugs, in part because Mojo typically (there are very large exceptions to this) compiles quickly. In a python context, I use the repl as a calculator when something grows beyond what gnome calculator supports, and notebooks for data exploration since they integrate nicely with pandas and plotting libraries, something which I will probably move over to Mojo once it’s ready.
I think the problem is that it returns object instead of a static type, and that most of the standard library doesn’t handle that properly. We also don’t have a great way to deal with things I think we’ll need, like Send/Sync marker traits that can’t easily be validated at runtime. I also don’t see a good way to, at runtime, validate that an object conforms to the API contract of a particular trait. While less of a concern for Python, Mojo can have safety invariants in trait API contracts that could result in UB if broken. I don’t see a good way to resolve this except via adding a bunch of extra information to traits about whether they have non-compiler-checked invariants, known as unsafe trait in Rust parlance. A lot of the external stdlib contributor discussions ended with “well what about Object?” blowing up type system discussions.
I don’t personally don’t see a way forwards that doesn’t either make def a second class citizen or require a lot of extra work to explicitly support object in libraries, work I’m not convinced will happen in most of the ecosystem.
AFAIK, def works fine today, except the implicit object return. def means that arguments can be mutated, that the function is implicitly throwable, and that it returns object. It sounds like you’re arguing that object is not-at-all baked, so breaking def off from it (for now at least, can always be reconsidered).
Julian here. I’d like to share my thoughts on the recent decision to remove REPL/Jupyter Kernel support, which I originally posted in a modified form on Discord:
It is unfortunate to see the removal of REPL/Jupyter Kernel support.
This decision might alienate some Python users, including myself.
I understand that your focus is on AI, GPU, and high-performance computing!
I also believe that Mojo does not need to be a complete superset of Python!
However, my initial excitement about Mojo stemmed from the following goals:
Solving the “two (or three) languages problem”: Many high-performance Python libraries are written in C/C++/Rust, making them challenging for Python users to work with. Mojo has the potential to address this issue.
Supporting interactive development (REPL/Jupyter Kernel support).
In my opinion, to gain traction, adoption, and become a widely used systems/AI/general-purpose language (rather than a niche AI/GPU language), Mojo should also focus on what makes Python great. Currently, it feels like Mojo is prioritizing the AI/GPU domain, leaving Python developers feeling like second-class citizens.
REPL/Jupyter Kernel support is, in my experience, one of the most critical features for many Python developers. It enables:
Interactive data analysis, exploration, and visualization (for data analysts, data scientists, and data engineers).
Exploring new libraries.
Testing APIs.
Debugging, prototyping, and testing.
Teaching and learning.
And much more.
As a side note I think modular accidentally created the dream language of many python devs (including myself).
Python syntax
static typing
compiled
fast & efficient
Modern tooling (project setup; dependency management; formatting; testing; benchmarking)
(interactive notebooks)
I really appreciate the transparency around the technical reasons behind this decision at this stage. I remain excited for Modular’s / Mojo’s future and hope that the community’s interest in interactive workflows will encourage the team to revisit this functionality down the line.
Thank you all for your feedback and for your patience. Yesterday, we issued a public statement regarding the Mojo REPL, addressing recent issues following the latest release–particularly concerning a key testing workflow that impacted several users. In hindsight, we realize that we made this statement without fully understanding all of the relevant use cases.
We truly appreciate the insights you’ve shared, and as a result, we’ll be engaging in more discussions to ensure we chart the best path forward for the REPL.
Thanks for your understanding. We’re committed to keeping you all updated as we work through this.
Also took the time to gather some data. As far as I can tell, def is fairly unpopular, at least among library authors, to the degree that it may be worthwhile to survey the Mojo community as to whether it’s actually a desired feature depending on the maintenance burden it imposes.
def has a very nice property - approachablity. For those new to the language it enables quick to understand and familiar construct. It also allows for progressive disclosure of complexity.
It is also useful in testing.
I think the original idea of def having a different default usefulfor quick scriptlike coding is still good.
I think the existence of def is tied deeply into the question of what Mojo is trying to be and which space it occupies in the programming language landscape. If you want to be poetic, I think it is a question about the “soul” of Mojo
I can totally see the argument against def: it’s an extra class of issues to deal with, and some of them can be quite gnarly, but I believe if Mojo is trying to achieve what I think it is trying to achieve then it is critical that def stays.
The def use case is mostly for “business logic” as opposed to library development.
This is a bit of an oversimplification, but I see Mojo going one of two ways:
Without def, Mojo effectively becomes the go-to language for writing fast performant libraries (especially in the ML/AI domain, but likely other places as well), that are mostly called from Python, i.e. replacing C/C++/Rust as the language that people use to write libraries for Python in. I.e. it doesn’t exactly solve Python’s two language problem, it just makes it a lot more palatable.
With def, Mojo does everything in point 1, but also replaces Python for the “business logic” side of programming, i.e. effectively solving Python’s two language problem (which as @JulianJS points out can be a real hassle). Python’s appeal (as can be seen by it’s popularity) is it’s ergonomics and ease of use, and without def it is hard to see how Mojo would compete on that front.
I think both of the above outcomes are positive, and achieving the first will definitely be easier than the latter, but I think the latter is worth attempting at least.
Could we please split the discussion about def off to its own dedicated topic in the Mojo section? It is pretty unrelated to the REPL, and you’ll get the right audience over there. Thx!
About the Interpreter/REPL/notebook:
even if power users don’t use it that much and the current focus is on gpu programming, I would say that a notebook interface does wonders for learning.
The current GPU tutorial in the Mojo documentation uses the REPL and a notebook extension in vscode. See GPU basics | Modular
So if the REPL is removed, this tutorial will have to be re-written and it may impact the learning of newcomers.
Also it would be amazing to have an easy way to run Mojo/max in google collab. It’s hard to overestimate the impact that accessing a notebook + a gpu in one click made on the AI community. It’s an incredible learning tool that could be use for GPU programming with Mojo. And it’s impossible to get this somewhat quickly without a working REPL/jupyter kernel.
It is pretty unrelated to the REPL, and you’ll get the right audience over there. Thx!