31
points
dmadisetti
Joined 46 karma
- We've addressed this too by allowing a setup cell:
The best part about this pattern is that it enables "pure" (only dependent on setup cell) functions to be addressable:... with app.setup: import numpy as np @app.cell def cell_uses_np(): # no np needed in signature result = np....
but nice convergent design :) glad to see to see we're addressing pain pointswith app.setup: from typing import Optional, Any @app.function def my_fn(arg: Optional[Any]) -> Any: ... - marimo has a quarto extension and a markdown fileformat [1] (marimo check works on this too!). The python fileformat was chosen such that "notebooks" are still valid python, but yes- the format itself is almost an implementation detail to most "notebook" users. Cells _are_ actually callable and importable functions though (you can give them a name), but the return signature is a bit different from what's serialized.
> 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!
- > But I really don't want to deal with yet another AI assistant, especially not a custom one when I'm already using Claude/etc from the CLI and I want those agents to help me edit the notebooks.
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
- Soft launched in pre-release, but a full version is coming!
- Arguments are typed if explicitly specified in definition, e.g.
We've talked about building out implicit typing into our serialization- but that may be a larger can of worms.```python @app.cell def my_cell(): x : int = 1 return (x,) @app.cell def consumer(x : int): y = x return ``` - marimo notebooks double as python Python programs, which means they can be lint-ed like any other code. `marimo check` catches notebook-specific issues (variable redefinition across cells, circular dependencies) with Rust-inspired (and uv; uv is amazing) error messages. It outputs JSON for AI agents to self-correct, integrates into CI pipelines, and includes `--fix` flags for automatic repairs. The team is already using it in their own CI and seeing Claude Code iterate on notebooks without human intervention.
- Hey, if your name had an accent, workspace creation should have failed
Not sure how we missed that in testing. But it should be good to go now
- I just turned off /notebooks in robots.txt
Our thoughts are the same as gists- Molab is built to share your work and give you a place to tinker. Please don't put your api keys in there
- Everyone knows prod doesn't break on the weekends
- I'm from a computational mechanics background, and my biggest issue with jupyter notebooks was doing analysis, playing around with my models, getting results I was happy with; then having my kernel break on a fresh session whenever I wanted to revisit the result.
You could argue this is a user issue, and being sloppy with cell state is a me problem- not a notebook problem- but marimo prevents this in the first place. Just once is already a wasted day's work. Even if one is especially diligent in Jupyter, they do not have the guarantees marimo provides. Unless you are pressing "restart and run all" in a Jupyter kernel every time - you are accumulating state.
I got started with marimo and helped build out the caching because I wanted to open up a notebook from scratch and automatically restart at the point I was at- without having to worry whether my cell order is correct or not. I wanted my code to automatically rerun update outputs if I changed something like a filtering or transform step to my data. I also wanted to go back to previous states easily without having to rerun long computations or deal with data dump versioning.
marimo's caching makes this all automatic.
The plan is to bring caching to an opt-in cell basis so this happens behind the scenes, with some ideas for handling side-effects like randomness and other "non-pure" cases.
But to answer your points, my use case has been specifically scientific computing. Yes for 1) prototyping- but also knowing my prototype does not hold some hidden state or bug. I have shown my advisor results, gone to deploy and been unable to replicate them at scale because of some hidden bug in my notebook execution. To me this is unacceptable. but also 2) documentation, notes, and report sharing. Not saving the outputs directly with the code isn't a blocker here, because caching automatically restores my state, and I can export to a more suitable format like a PDF or HTML file if I need to share it. Saving generated binaries in source for any other setup would be considered poor form- I don't understand why Jupyter gets a pass here. "Write once" is a google doc, notebooks should be "run many times", i.e. reproducible and sharable.
Hopefully, we get to address some of the other pain points with existing infrastructure; like auto-scaling on HPCs (easy for marimo, it's already a DAG); integrating code more directly into papers (we have mkdocs, and experimental quarto extension exists); and built-in environments (no more `pip install -R requirements.txt` on a paper project and hoping the authors remembered to freeze and pinned versions)
---
Hope my tone doesn't come off too contentious- I've just been burned by Jupyter and I'm excited because I feel like marimo addresses its major issues.
- Very excited for the top level functions change coming up !!
- Doesn't need to be perfect- but using this would actively reduce productivity
- Yeah, they're not exactly a scrappy startup- I'd be surprised if they had 0 QA.
Makes me wonder if they internally have "press releases / Q" as an internal metric to keep up the hype.
- I feel like pytomls and shared source are becoming standard, but yes-
notebooks vs research code are sometimes very separate, very difficult to directly reproduce. A big difficultly with "working out of the box, shared in browser" is that weights, training, inference, simulations- are all still very compute intensive.
BUT the nice thing about a stateless notebook, is that you can precompute values- and cache them. I've been really excited about expanding marimo's caching system, and would love to get to a point whether sharing a notebook means being able to run the research yourself without some big setup dance.
- The beta is inconsistently showing (required a few refreshes to get something to show up), but my limited usage of it showed a plethora of issues:
- Assumed UTC instead of EST. Corrected it and it still continued to bork
- Added random time deltas to my asked times (+2, -10 min).
- Couple notifications didn't go off at all
- The one that did go off didn't provide a push notification.
---
On top of that, only usable without search mode. In search mode, it was totally confused and gave me a Forbes article.
Seems half baked to me.
Doing scheduled research behind the scenes or sending a push notification to my phone would be cool, but surprised they thought this was OK for a public beta.
- ``` meme2txt distracted_boyfriend.png \ --meme "the internet" 9 68 black \ --meme "classic memes" 16 80 black \ --meme "$(toilet "meme2txt" -fsmblock)" 30 40 white ```
Sure, it seems a little frivolous- but I threw together the script as a way to get one of my friends more interested in hacking. On that front, I succeeded.
- 2 points
marimo doesn't support creatine :)