akshayka

Hello from the original creator of marimo. We now default to putting outputs below cells (feedback heard!). Pluto.jl was a significant inspiration in marimo’s original design.

Thanks for the kind words.

We've had the same thought, and are experimenting in this direction in the context of recursive language models.

Let us know if you have feedback!

You have good timing. Earlier today we announced an agent skill that drops Claude into a running marimo notebook session, allowing it to run code in the marimo kernel (read variables, test logic, get feedback when errors like multiple definitions are hit, add and remove cells, manipulate UI elements ...):

https://news.ycombinator.com/item?id=47678844

Hello from the original creator of marimo. Do you have teaching materials to share? I would love to see how one might teach Python with a reactive notebook

See the corresponding Show HN from earlier today for a technical overview. There are some interesting components, such as the LSP-based implementation and the integration with uv

https://news.ycombinator.com/item?id=45982774

This is Akshay, the original creator of marimo. Our whole team has come over to CoreWeave. We're building a whole lot more, not less, and our number one priority continues to be the open-source. We're also growing the open-source team, i.e. we're hiring.

Anecdotally it seems like most software engineers have heard of linear programming, but very few have heard of convex programming [1], and fewer still can apply it. The fixation on LPs is kind of odd ...

[1] https://github.com/cvxpy/cvxpy

Hi! Thanks for your interest. marimo is much more than that — unlike traditional notebooks, marimo is "reactive", meaning it models notebooks as dataflow graphs and keeps code an outputs in sync. Moreover, marimo notebooks are not "just notebooks". They can be seamlessly run as interactive web apps or as Python scripts.

Here is our original ShowHN post that explains what marimo is all about: https://news.ycombinator.com/item?id=38971966

Blog that goes deeper: https://marimo.io/blog/lessons-learned

You can not use the AI features, nothing is enabled by default (you have to bring your own keys)

For startups that have an open-source component, GitHub is a good channel. That's how our first hires came to marimo.

Thanks for the feedback. We decided early on against having a “non-reactive” mode. It would negate many of our core benefits (including importing from other notebooks), and it would also lead to a fragmented ecosystem — if someone shared a notebook with you, your experience with it would depend on whether it was executed in “reactive” or “non-reactive” mode. Still I appreciate the kind words about our editor and file format, and am sorry we can’t accommodate your use case.

We describe why we opted against “disabling” the graph at the end of this blog: https://marimo.io/blog/lessons-learned

Sorry I forgot the link. We have shortcuts for those as well. If any are missing please file an issue and we can consider adding them.

I forgot the link: https://docs.marimo.io/guides/editor_features/overview/#conf...

What kind of muscle memory is holding you back? We recently added support for Jupyter-style command mode in keyboard shortcuts [1]. We're currently rewriting our VS Code extension to feel native, similar to how Jupyter feels in VS Code.

Anything else we can help with?

Thanks for the shoutout!

We're committed to having an excellent experience for working with expensive notebooks [1]. At least for my own personal work, I find that there are many reasons to use marimo even when autorun is disabled — you still get guarantees on state, rich dataframe views, reusable functions [2], the Python file format, and more. If you have feedback on how we might improve the experience, we'd love to hear it.

[1] https://docs.marimo.io/guides/expensive_notebooks/

[2] https://docs.marimo.io/guides/reusing_functions/

Thanks for the comments. I'm the original creator of marimo.

Habitually running restart and run all works okay for very lightweight notebooks, but it's a habit you need to develop, and I believe our tools should work by default. It doesn't work at all for entire categories of work, where computation is heavy and the cost of a bug is high.

From the blog, you will see that reactive execution not only minimizes hidden state, it also enables rapid data exploration (far more rapid than a traditional notebook), reuse as data apps, reuse as scripts, a far more intelligent module autoreloader, and much more.

marimo is not just another Jupyter extension, it's a new kind of notebook. While it may not be for you, marimo has been open source for over a year and has strong traction at many companies and universities, including by many who you may not view to be "real devs". The question of whether marimo will catch on has already been resolved :)

https://github.com/marimo-team/marimo

Very nice. Here's a one liner for marimo notebooks:

uvx marimo edit

A one liner with marimo that also respects (and records) inline script metadata using uv:

uvx marimo edit --sandbox my_notebook.py

https://docs.astral.sh/uv/guides/integration/marimo/

More than that. marimo.app runs in the browser with WASM. That makes for a snappy experience but is limited in RAM and what kinds of packages can be run. This runs Python on a traditional backend, letting you use any package and any more resources.

We've got you covered: https://www.youtube.com/live/cYtWzIaGvb4?si=ZbhWEQBBv15yo8eq

Hi! molab is not available for self-hosting. For self-hosting, you have a few options:

Use marimo open source. This can be self-hosted in the same way that Jupyter can. Repo: https://github.com/marimo-team/marimo

Use marimo's WebAssembly notebooks (exporting to WASM-powered HTML). For example, that's how Cloudflare is sharing marimo notebooks currently: https://notebooks.cloudflare.com/. Docs: https://docs.marimo.io/guides/exporting/#export-to-wasm-powe...

Use within JupyterHub: https://github.com/jyio/jupyter-marimo-proxy

If your notebooks need keys, use mo.ui.text(kind=“password”), similar to the example from Hugging Face: https://molab.marimo.io/notebooks/nb_jpcTRt2jckij9iujuZ6NuZ

Thanks! Notebooks on molab are public (but undiscoverable, like public GitHub gists), and can be shared with links. This is described here: https://marimo.io/blog/announcing-molab.

Sorry! Did the notebook not connect to the runtime? Notebooks usually start quickly but there is variance, which we are working to tighten. If you have a notebook link/ID, we can look into it.

Thanks for the kind words. Many of our users have switched entirely from Jupyter to marimo for experimentation (including the scientists at Stanford's SLAC alongside whom marimo was originally designed).

I have spent a lot of time in Jupyter notebooks for experimentation and research in a past life, and marimo's reactivity, built-in affordances for working with data (table viewer, database connections, and other interactive elements), lazy execution, and persistent caching make me far more productive when working with data, regardless of whether I am making an app-like thing.

But as the original developer of marimo I am obviously biased :) Thanks for using marimo!

marimo still allows you to run cells one at a time (and has many built-in UI elements for very rapid experimentation). But the distinction is that in marimo, running a cell runs the subtree rooted at it (or if you have enabled lazy execution, marks its descendants as stale), keeping code and outputs consistent while also facilitating very rapid experimentation. The subtree is determined by statically parsing code into a dependency graph on cells.

Thanks Simon for the kind words!

For those new to marimo, we have affordances for working with expensive (ML/AI/pyspark) notebooks too, including lazy execution that gives you guarantees on state without running automatically.

One small note: marimo was actually first launched publicly (on HN) in January 2024 [1]. Our first open-source release was in 2023 (a quiet soft launch). And we've been in development since 2022, in close consultation with Stanford scientists. We're used pretty broadly today :)

[1] https://news.ycombinator.com/item?id=38971966

It's indeed very easy to try locally! For example in a marimo notebook, just a few lines of code: https://www.youtube.com/watch?v=x6YtqvGcDBY

(Disclosure, I am a developer of marimo.)

You can try marimo notebooks, which are stored as pure Python and support SQL cells through duckdb. (I’m one of its authors.)

https://github.com/marimo-team/marimo

Hi; I'm the author of this post, and one of marimo's original developers. Thanks for taking the time to read this post, and for looking at marimo.

With Marimo, can I check the outputs directory into version control in a reasonable way and have it stored for posterity? Is that .ipynb?

You can snapshot to ipynb automatically while a marimo notebook is running, or after the fact. You can also snapshot as HTML, which marimo can hydrate back into a notebook.

Is there a way to convert a stored .ipynb checkpoint back into the marimo format?

Yes, `marimo convert notebook.ipynb -o notebook.py`.

marimo was originally commissioned by, and designed in collaboration with, scientists at Stanford's SLAC National Laboratory. These scientists were heavy users of Jupyter, but decided they needed something like marimo to solve two main problems they encountered with Jupyter notebooks: computational reproducibility, and publishing interactive science communication on the web.

We have co-authored an article with these scientists, explaining how these problems and how marimo solves, which you can read here: https://marimo.io/blog/slac-marimo.

From our article:

In 2019, a study from New York University and Federal Fluminense University found that of the 863,878 Jupyter notebooks on GitHub with valid execution orders, only 24% could be re-run, and just 4% reproduced the same results.

Many scientists (these scientists and myself) use notebooks as a critical part of the scientific process. Jupyter notebooks are notorious for being plagued with reproducibility issues due to hidden state, to the extent that the authors of Jupyter wrote a paper titled "Ten simple rules for reproducible research in Jupyter notebooks" [1]. In my mind, these rules are not simple nor convenient. One is to periodically restart the kernel to make sure you don't accumulate hidden state — untenable for expensive notebook. Another rule is in fact to use version control (Git):

Version control is a critical adjunct to notebook use, because the interactive nature of notebooks makes it easy to accidentally change or delete important content. Furthermore, since notebooks contain code, and code inevitably contains bugs, being able to determine the history of when a given bug you have discovered was introduced to the code vs when it was fixed – and thus what analyses it may have affected – is a key capability in scientific computation.

In my own PhD, I used Jupyter notebooks extensively to see my data while I worked on it, and to produce figures for papers [2]; sometimes, these notebooks took a very long time to run. I have a background in software engineering, so I was able to make my notebooks more or less reproducible, though I wasted many hours debugging inconsistencies due to hidden state (one example: delete a cell, but its variable are still in memory!) My co-authors, however, often did not have a background in software. They also used Jupyter notebooks. But when I tried to run their notebooks, either they didn't work at all (packages and computational environment not properly documented), or when running I got different results than the ones serialized in the notebook (notebook author ran cells out of order, or ran side-effecting cells multiple times, etc -- hidden state). This was a huge problem and really a non-starter for computational science.

Yes, you can get Jupyter/Ipykernel to work for you if you try hard enough, if you are experienced enough, and if you are willing to eat enough pain (sometimes literally -- I know of someone who got an incorrect tattoo due to hidden state in a Jupyter notebook that rendered a design for their tattoo; the notebook author forgot to "restart and run all" after making a change). But the imperative nature of the REPL makes it a fundamentally error-prone experience. Our philosophy with marimo is that notebooks should be reproducible by default.

Hope this helps. It's still possible that marimo is not for you, but at least for scientists who use notebooks to conduct research, or want to share interactive articles on the web without paying for compute, I do believe it has something compelling to offer over traditional notebooks like Jupyter.

[1] https://arxiv.org/pdf/1810.08055 [2] https://web.stanford.edu/~boyd/papers/min_dist_emb.html

Yea. This blog post is definitely written for software-minded people who work with data. We do have another post that explains some of the problems that marimo hopes to solve for scientists, chief among them computational reproducibility and publishing interactive science communications on the web: https://marimo.io/blog/slac-marimo

It’s true that we don’t store outputs in the file format. This is the main tradeoff, as discussed in the blog. But that doesn’t mean marimo notebooks aren’t suitable for heavy computation.

marimo lets you automatically snapshot outputs in an auxiliary file while you work. We also have a persistent cache that lets you pick up where you left off — saving not just outputs but also computed data.

Many of our users do very heavy computation.

https://docs.marimo.io/guides/expensive_notebooks/