My understanding is it’s just python code with a bit of notebook hints and an idea that gives the notebook experience.
So I didn’t quite catch from the article why ruff and pylons aren’t enough.
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
Jeremy Howard (fast.ai, etc) posted a few weeks ago about his new AI class [1] and I was pumped. I went through the fast.ai course a couple years ago and had been wondering if another would ever come out, and the overview of this sounded really interesting. But the first thing the announcement went into was Jupyter Notebooks, and it kept on and on about them and I rolled my eyes. I remember they were my least favorite part of the fast.ai class. They've always felt awkward to me, being used to a code editor and all the functionality it provides, and I'm sure I'm not alone.
I'm sure Jupyter is great for fast iteration if that's what you do all day, but if you spend most of your life in a standard code editor, you really want something that starts from there and adds a bit of interactivity on top, rather than jumping to a completely different concept. I haven't tried marimo yet, but I might give it a shot for my next project.
Also, I find the way Marimo uses decorators and functions for defining cells pretty awkward (Although it’s nicely abstracted away in the UI). It looks like normal Python, but the functions don’t behave like real functions, and decorators are a fairly advanced feature that most beginners don’t use.
For me, Quarto notebooks strike a better balance when it comes to generating sharable documents, prototypes, and reports. They’re git-friendly, use simple markup for defining cells, and still keep the clear, linear structure.
However, Marimo might be the best tool for replacing Streamlit apps and “production notebooks” (Although I’d also argue that notebooks should not be in production).
> The discipline of keeping cells in order may be painful, but it’s what makes the flow of analysis understandable to others.
We might have to agree to disagree here, you can still chose to have your notebook in order and something you can be disciplined about. The difference is that a marimo notebook can't become unreproducible the same way a jupyter notebook can, _because_ the order doesn't matter.
But thanks for the feedback!
Take out all the AI stuff and I'd give it a try. I use AI coding agents as my daily driver, but I really don't need this AI enshittification in every tool/library I'm using.
# %%
import polars as pl
# %%
df = pl.DataFrame()
df.shape
# %%
def foobar():
return 1
Since it is a regular .py file all of your existing tooling will work with it. The one thing you lose vs a Jupyter notebook is saved output. I mostly use these .py files, but have a few .ipynb notebook files for when I want to commit the output from some important task.That's actually pretty slick. I've been wondering how we could avoid blocking innovation in programming languages because of the death cycle of "no training data on language -> LLM can't learn language -> Assistant can't code language -> nobody uses language -> no training data on language".
So funny story- you can use exactly the same CLI tools in your notebook. Zed built out the ACP spec [1] which lets Claude Code go anywhere that implements it (as of Oct 2nd; emacs, vim, zed and marimo [2])
[1]: https://github.com/agentclientprotocol/agent-client-protocol
dmadisetti•4mo ago
aitchnyu•3mo ago
sixo•3mo ago
dmadisetti•3mo ago
sixo•3mo ago
dmadisetti•3mo ago
sixo•3mo ago
Imports ARE the case where untyped cell arguments are most annoying, but of course it would be nice to get it for free in all cases.