4 ms·

As far as I'm concerned, reactive state management is a solved problem. Use SQLite for everything, or Postgres if you outgrow it. Does it require a bunch of glu

As far as I'm concerned, reactive state management is a solved problem. Use SQLite for everything, or Postgres if you outgrow it. Does it require a bunch of glue code? Depends on the language, but let's say it does. This orthogonal persistence layer of Cell's is guaranteed not to do a fifteenth of what SQLite does, so either you lose out on it, or you're back to square one with the glue code.

obeavs 3y ago
> Use SQLite for everything, or Postgres if you outgrow it. Or both! I've followed ElectricSQL for a while and it's pretty awesome to see how they've approached it. Rest APIs replaced with client side SQLlite which syncs to server side postgres over a CRDT layer that you don't actually have to touch/know anything about. And they just rebuilt postgres on pure WASM (https://github.com/electric-sql/pglite https://github.com/electric-sql/pglite). It's just cool to think that maybe you don't have to do design all of these intricate REST apis and just call SQL.
vczf 3y ago
I think you're too quickly dismissing the potential benefits. From the FAQ[1]: The combination of all the above properties, plus the fact that I/O is also separate from pure computation and updates, enables a number of features that are not found in conventional languages. The first one is the ability to "replay" the execution of a Cell program. One can easily reconstruct the exact state of a Cell program at any point in time. Obviously that's very useful for debugging, but there are others, more interesting ways of taking advantage of that. It's for example possible to run identical replicas of the same Cell process on different machines over a network, and that's something that will be crucial in Cell's future network architecture. The second one is orthogonal persistence, that is, the ability to take a snapshot of the state of the application (or part of it), which can then later be used to create with minimal effort an identical copy of it, that will behave in exactly the same way. In Cell, you don't save your data the way you do it in conventional languages. Instead, you simply declare which parts of your application's data structures have to be persisted, and the compiler generates for you all the code needed to save and load them. Is it as robust as using a mature technology like SQLite? Obviously, no. But these are interesting ideas that lead somewhere new. [1]: https://www.cell-lang.net/faq.html https://www.cell-lang.net/faq.html
- mncharity 3y ago
  > replay When you want quick response to keypress, and yet app state also depends on high-latency ML pose or gesture analysis waiting on camera frames, and spoken "Launch the missiles!" can become "Lunch is mussels! In butter!", replay with improved understanding of past input is nice.
deleted 3y ago
[deleted]
macintux 3y ago
I find it odd that anything in this space can be considered a solved problem. Let’s not abandon new ideas just because we can glue together something.

obeavs 3y ago

> Use SQLite for everything, or Postgres if you outgrow it. Or both! I've followed ElectricSQL for a while and it's pretty awesome to see how they've approached it. Rest APIs replaced with client side SQLlite which syncs to server side postgres over a CRDT layer that you don't actually have to touch/know anything about. And they just rebuilt postgres on pure WASM (https://github.com/electric-sql/pglite https://github.com/electric-sql/pglite). It's just cool to think that maybe you don't have to do design all of these intricate REST apis and just call SQL.

vczf 3y ago

I think you're too quickly dismissing the potential benefits. From the FAQ[1]: The combination of all the above properties, plus the fact that I/O is also separate from pure computation and updates, enables a number of features that are not found in conventional languages. The first one is the ability to "replay" the execution of a Cell program. One can easily reconstruct the exact state of a Cell program at any point in time. Obviously that's very useful for debugging, but there are others, more interesting ways of taking advantage of that. It's for example possible to run identical replicas of the same Cell process on different machines over a network, and that's something that will be crucial in Cell's future network architecture. The second one is orthogonal persistence, that is, the ability to take a snapshot of the state of the application (or part of it), which can then later be used to create with minimal effort an identical copy of it, that will behave in exactly the same way. In Cell, you don't save your data the way you do it in conventional languages. Instead, you simply declare which parts of your application's data structures have to be persisted, and the compiler generates for you all the code needed to save and load them. Is it as robust as using a mature technology like SQLite? Obviously, no. But these are interesting ideas that lead somewhere new. [1]: https://www.cell-lang.net/faq.html https://www.cell-lang.net/faq.html

mncharity 3y ago
> replay When you want quick response to keypress, and yet app state also depends on high-latency ML pose or gesture analysis waiting on camera frames, and spoken "Launch the missiles!" can become "Lunch is mussels! In butter!", replay with improved understanding of past input is nice.

deleted 3y ago

[deleted]

macintux 3y ago

I find it odd that anything in this space can be considered a solved problem. Let’s not abandon new ideas just because we can glue together something.