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
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.
sure sure, but I've been at an acquisition and we have seen countless more in the wild, the founders lose control over time and the parent company will do what they like, acquisition is a big red flag for me when considering adoption of a project
you can say whatever you want, but we have history to help guide us, and it has not been kind to the acquisitioned company's current user base
you're still in the honeymoon phase, check back with us in a year or two
From the looks of it, CoreWeave is a crypto company now turned AI company, currently offering infrastructure/cloud services. Definitely no focus on data or developer tools.
(Also see the recent "CoreWeave is a time bomb" recent articles here, https://hn.algolia.com/?q=CoreWeave).
It's sad Marimo got sucked up into this, I fully expect it will not receive the love and support it deserves, especially now that it was shaping up to be an amazing tool. I can only hope it will fail quickly and painfully, so as to spawn an open source fork that will outlast the AI bubble.
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 ...
I’m a software engineer who has been trained on convex programming. I have read the Boyd book, did some hobby projects in the area. But it is just not comming up during the day to day work. Even when i have a task well suited for continous value optimisation it does never seem to be a good fit for convex programming. The application areas were sensor calibration, slam, model predictive control, trajectory prediction and the like. Usually when this happens we just throw the problem at ceres solver and deal with it when it is not converging. Would be nice to have the strong guarantees a convex optimiser could give us but I’m not finding a way in practice.
It is probably just a “git gud” situation. I even re-read Lars Blackmore’s “Lossless Convexification of Nonconvex Control Bound and Pointing Constraints of the Soft
Landing Optimal Control Problem” from time to time hoping that i find a way to apply a similar convexification idea to my problems. With all of that I’m not that surprised that convex optimisation is not more widely known.
I feel software/CS people largely avoid (or don’t need) certain areas of math.
To me, convex optimization is more the domain of engineering when there are continuous functions and/or stochastic processes involved.
Much of signal processing and digital communication systems are founded around convex optimization because it’s actually a sensible way to concretely answer “was this designed right?”.
One can use basic logic to prove a geometry proof, or the behavior of a distributed algorithm.
But if one wants to prove that a digital filter was designed properly for random/variable inputs, it leads to finding solutions of convex optimization problems (minimization of mean squared error or such).
Of course, whether the right problem is being solved is a different issue. MMSE is just mathematically extremely convenient but not necessarily the most meaningful characterization of behavior.
I’ve always thought it was weird too, and have spent far too much time thinking why - my best guess is that it’s used in Economics while other methods aren’t used outside programming curiosities (unless you need to apply it at work)
CP sits in a weird place between LP and general global optimization solvers. You need to study the solution space to make sure it is not higher order than CP can handle. And if your analysis fails, you may end up with local optimization. It is much easier to figure out if the problem is linear. So might as well switch to GA instead of risking it with CP.
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.
I was just thinking about something like this a couple hours ago.
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.
Maybe. At least that way it doesn't feel like some separate half-baked proprietary code editor from the 90s, which is the vibe I get from Jupyter. But a regular .py file with a couple attributes that can generate notebooks still sounds far nicer, assuming it works fairly seamlessly.
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.
Ah that's great to hear. For me it is mostly the command mode. Is it only create / copy / paste for now? Can I also do the same for move / split / delete / undelete?
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.
I haven’t tried marimo, so I’m not sure how it currently works, but I think instead of disabling autorun for slow and expensive computations, it sounds like it would be nicer if there were heuristics or benchmarks to automatically determine what might be slow and then execute things in varying orders lazily.
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 :)
I would consider replacing my jupyterlab usage with marimo were it less opinionated about workflow - it offers a lot of benefits that aren't tied to its execution model. I like the editor/interface and the representation as python files for portability, version control, and the ability to import from other notebooks, but I have no interest in changing my workflow (in particular insofar as marimo is restricted compared to python itself). E.g., I want to be able to redefine variables and use star imports in my personal, exploratory notebooks, and I'm happy to retain responsibility for top-to-bottom executability (as in regular python scripts). I would definitely consider marimo if these restrictions could be opted out of if one has reactive execution disabled.
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.
https://news.ycombinator.com/item?id=45982774