Comments URL: https://news.ycombinator.com/item?id=48749819

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=46619720

Points: 2

# Comments: 1

marimo doesn't support creatine :)

    ...

    with app.setup:
        import numpy as np
    
    @app.cell
    def cell_uses_np():
        # no np needed in signature
        result = np....

    with app.setup:
        from typing import Optional, Any

    @app.function
    def my_fn(arg: Optional[Any]) -> Any:
        ...

> 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!

[1]: https://github.com/marimo-team/quarto-marimo

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

[2]: https://zed.dev/blog/acp-progress-report

    ```python
    @app.cell
    def my_cell():
        x : int = 1
        return (x,)

    @app.cell
    def consumer(x : int):
        y = x
        return
    ```

Comments URL: https://news.ycombinator.com/item?id=45509301

Points: 31

# Comments: 23

Not sure how we missed that in testing. But it should be good to go now

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

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.

Makes me wonder if they internally have "press releases / Q" as an internal metric to keep up the hype.

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.

- 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.