I’m not familiar with Deepnote, but I have quite a lot of experience with Jupyter, and if someone were to ask me if there are more modern alternatives I would immediately point them to marimo (https://marimo.io/). For me marimo is already a successor to Jupyter, it has replaced it entirely for me.
But doesn't marimo force certain workflows that jupyter does not? For example its website states that "Notebooks are executed in a deterministic order, with no hidden state — delete a cell and marimo deletes its variables while updating affected cells." This appeals to people doing traditional software development work in notebooks, but it breaks workflows where people use notebooks as notebooks, where state is entirely separate from the in-notebook presentation of cells. Do people using notebooks these days hate this fundamental feature of notebooks? It's the key reason why notebooks aren't just a transcript of a REPL session!
> Do people using notebooks these days hate this fundamental feature of notebooks?
It's one of the things that is the most confusing to people I've worked with. The idea that there is hidden state and you have to re-run cells to get variables to update (or variables still exist when you've deleted those cells) is quite confusing.
If you're trying to have a reproducible workflow, it can be difficult. Jupyter is no different from other notebooks in this regard (RStudio, for example will happily run code and keep variables around that you don't reference any longer in your .R or .Rmd files.)
But I see your point -- if you're using it as a long-term storage notebook, then this is the expected behavior. And you absolutely want to have "historical" data/results kept.
I generally think of / use notebooks as a way to make reports for analyses. So, I want to work with them, draft them, change them, put them in git, etc... then run them all at once to get my output. For me, having a reproducible, documented workflow is more important. I don't want state to be kept outside of those one-off runs. Really until your comment, I didn't understand the other side of the issue, so thanks!
Yup, Marimo seems perfectly gittable and Deepnote looks more of the status quo.
> Human-readable format: The .deepnote YAML format replaces .ipynb's messy JSON with clean, version-control and human-friendly structure for projects and notebooks. You can organize multiple notebooks, integrations, and settings into a single .deepnote project for better structure and collaboration.
I confess that picking yaml doesn't feel safe to me. As much as it annoys people, fenced formats are the way, here. And if you aren't careful, you are going to recreate XML. Probably poorly.
Check out their YouTube channel where they show plenty of interesting features. But just to list some I can think of:
- optional reactivity (i.e. you create chain of cells where editing 5th cells in the past causes update down the stream, pretty neat when working with dataframes). Its reactivity is a very cool feature once used to but you might not want it for something like running heavy ML training task so it can be toggled off
- you can switch notebook to multi-column notebook mode
- notebook is a web app that has sidebar with a lot of menus, there cool sections like Docs, Packages (you can download new packages right away there with uv), plenty of LLM integration with their custom prompts where you can reference dataframes so that it would be able to understand schema, some SQL and other DB integrations as well, cells can even contain SQL instead python code and output query result into python variable
- thanks to reactivity it got a lot of interactive elements like sliders buttons text fields or ability to create entire own widgets, there's even mode where all code blocks get hidden and you're left with complete app
- you can make web export of notebook that will translate python to WASM and publish it as fully working static page (though publishing something heavy complex like torch probably won't go well), this fits well with previous point as you can basically build simple interface hide all the code and publish it (like imagine matplotlib with couple of sliders)
- DataFrames (pandas/polars) displayed as interactive tables where you can filter by columns, scroll through pages of rows etc
- notebook stored in a .py format, unlike .ipynb with its json like structure. So code is very Git-friendly but you don't store computation results anymore
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.
Thanks for the link. I'm not a subscriber to their blog and would otherwise not have known about this change that affects the recommendations I have been giving people.
I found it because they proudly present it at the top of their web pages, it only happened last thursday, so understandable people are not familiar with the fact it is under new management
It's not reasonable to expect a source code management system to display the last output of every Python script.
It might have been convenient for Jupyter notebooks, but that was a side effect of what's essentially a negative feature, the last output of every cell being thoroughly mixed with the source code.
You may see it as a negative feature, but i see it as a positive feature. I can push my notebooks to GitHub with the outputs and share them with others. Those people can see what the results are without having to setup and run the notebook.
This is incredibly useful for knowledge sharing and learning
Oh don't get me wrong, I have nothing against publishing notebooks, on GitHub or anywhere else. That was the convenient part. The negative feature was Jupyter mixing output into the file source code, making it difficult to version.
I never really liked Jupyter. I've built a couple of "notebooks", as they have come to be known the days, much better than Jupyter and still switched to marimo, eventually. Quite similar to what I wanted to have.
The overlap with Jetpack's devbox name is not fine. Not morally, given the massive overlap in functionality between the two implementations. At the very least, their existence will prevent you from getting a trademark.
Both projects even use devbox.json for their definitions, for crying out loud. If your usage is not compatible with Jetpack's devbox.json, please switch to a different filename ASAP.
Good point. I remember testing out Jetify's version a while back and switching away from it due to some issue I was having. I 100% thought this project was the same, just with a new website, as I did not remember much of the implementation details. Both of them even use `devbox.json` as the configuration file...
Well its not the same programming wise so your problem might be fixed on ours but as i said in another reply i wasnt aware of the existing project and our overlaps i did no research before hand sadly
We're currently moving multiple projects from Sentry to Bugsink, and so far it's looking great, thanks for making this @vanschelven :)
No hate on Sentry by the way, but we (and some of our clients in the Netherlands) also like to have a European alternative, and it's a big bonus that this has a very low switching cost.
Indeed @vanschelven, django-hidp (Hello, ID Please) is our newly open-sourced full-featured authentication system for Django projects that we’ve just soft-launched. We were getting ready to post this on HN, but since this is here now, I thought we might just chime in on the discussion.
Current status of django-hidp is we’re still refining the documentation and building the website, but the core functionality is solid, and already in use for quite a lot of our clients. As such, we would say it's ready for evaluation by interested Django developers.
So, if you’re interested in a comprehensive authentication system for Django projects, django-hidp offers:
- comprehensive authentication: user registration with email verification, login, password reset, and more
- OpenID Connect (OIDC) support: built-in support for integrating with providers like Google and Microsoft
- One-Time Passwords (OTP): based on django-otp, with flexible flows and policies
- rate limiting: protects against brute-force attacks
- Content Security Policy (CSP): helps prevent cross-site scripting and other code injection attacks
- standalone OIDC Provider: can be configured to act as its own OIDC provider
- and a lot more...
Designed with OWASP best practices in mind, django-hidp aims to provide a secure and flexible solution for user authentication in Django projects. Without having to reinvent any wheels (no pun intended) and combining slews of dependencies together into a coherent whole. We've already done that quite a lot of times in the past, and now we finally sat down to that work for you, and build an opinionated, batteries-included application that can be used in all Django projects.
If you have any questions, or would like to know more, please reach out to me.
