3 ms·

> marimo makes it seamless to go from prototype to production. No, it doesn’t. In fact, no tool; not retool, not any of no-code solutions, free or paid, lets

> marimo makes it seamless to go from prototype to production. No, it doesn’t. In fact, no tool; not retool, not any of no-code solutions, free or paid, lets you take a hacked up prototype and seamlessly put in into production. In fact, even claiming that it does makes me question the other (superficially quite laudable) things it claims to do; eg. plain python files. Why do people go down these rabbit holes? You can’t run prototype notebooks for your production workloads. It’s not because it’s fundamentally impossible to use a notebook as a platform for robust production code. …it’s because prototyping means quick hacks, quick dirty unmaintainable hacks. > Run your notebook as a web app, with Python code hidden and uneditable Why? Stop. No. Don’t make your prototype hacked up notebook that has probably got direct system access public. You at least are password protecting this right? No? (https://github.com/marimo-team/marimo/issues/395 https://github.com/marimo-team/marimo/issues/395) What part of don’t accept every damn idea as a feature did you not take to heart? -_- There are a lot of ideas in this project. A LOT of ideas. Some of them are good. Some of them are fully implemented.

akshayka 2y ago
token/password protection is in the works; just designed it with my co-maintainer yesterday.
mscolnick 2y ago
production != public, in most cases. If you are making things public, you likely care about more than just a password, which you'll want to push into an auth gateway with oauth support, authZ, rate-limiting, etc.
fifilura 2y ago
Yours is the fundamentalist view and it always has its place in the debate. But it is not necessarily what the organization needs. There are benefits of running notebooks in production rather than reimplementing things in another environment. 1. The prototype is tested and verified. And I don't mean tested as in 50 unit tests and integration tests. But tested in the way that a human actually looked at the result and was satisfied. Reimplementing means that you will start from scratch. 2. That the production env is the same as the analysis env means that it is trivial to go back and debug issues. 3. Sometimes maybe what you need is a fast solution. Not sending stuff into the scrum loop of a separate engineering team and pray it makes it into a sprint not so far away. TL;DR get shit done.
- keithalewis 2y ago
  If the target is C++ you can use my library https://github.com/xlladdins/xll https://github.com/xlladdins/xll. It makes it easy to call C++ from Excel.
Kalanos 2y ago
.py is undeniably more widely compatible in production envs than .ipynb

akshayka 2y ago

token/password protection is in the works; just designed it with my co-maintainer yesterday.

mscolnick 2y ago

production != public, in most cases. If you are making things public, you likely care about more than just a password, which you'll want to push into an auth gateway with oauth support, authZ, rate-limiting, etc.

fifilura 2y ago

Yours is the fundamentalist view and it always has its place in the debate. But it is not necessarily what the organization needs. There are benefits of running notebooks in production rather than reimplementing things in another environment. 1. The prototype is tested and verified. And I don't mean tested as in 50 unit tests and integration tests. But tested in the way that a human actually looked at the result and was satisfied. Reimplementing means that you will start from scratch. 2. That the production env is the same as the analysis env means that it is trivial to go back and debug issues. 3. Sometimes maybe what you need is a fast solution. Not sending stuff into the scrum loop of a separate engineering team and pray it makes it into a sprint not so far away. TL;DR get shit done.

keithalewis 2y ago
If the target is C++ you can use my library https://github.com/xlladdins/xll https://github.com/xlladdins/xll. It makes it easy to call C++ from Excel.

Kalanos 2y ago

.py is undeniably more widely compatible in production envs than .ipynb