3 ms·

> The state of the application can be partitioned in separate components (called automata) that do not share any mutable state and can be safely updated concurr

> The state of the application can be partitioned in separate components (called automata) that do not share any mutable state and can be safely updated concurrently. This is the right direction! Pure computations on (somewhat) centralized data has proven to be very resilient to bugs. It's kind of like how React organizes its programs. I like how Cell is tackling this problem at the language level. A language's programs will (in practice) often be a reflection of what the language makes easy and what it makes hard, so designing a language to handle this complexity would be a boon to the world. Pony also has this via its `iso` keyword and actors [0]. Cone is also exploring this notion, with an interesting actor/async/await hybrid [1]. > 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. This sounds like Vale's "Perfect Replayability" feature [2] which captures all IO for a program and deterministically replays it. It's an incredibly useful feature, and I hope Cell exposes it well! [0] https://tutorial.ponylang.io/reference-capabilities/reference-capabilities.html https://tutorial.ponylang.io/reference-capabilities/referenc... [1] https://cone.jondgoodwin.com/ https://cone.jondgoodwin.com/ [2] https://verdagon.dev/blog/perfect-replayability-prototyped https://verdagon.dev/blog/perfect-replayability-prototyped

tacotacotaco 4y ago
> A language's programs will (in practice) often be a reflection of what the language makes easy and what it makes hard… In industrial design this is called an affordance. The product is designed to encourage correct usage and make incorrect usage difficult. I would like it if more language designers will carefully consider their language’s features like this. The Elm language is a good example.
pca006132 4y ago
Ｉ think this may also be a good way to separate libraries from application code, by considering the library as another actor instead of a direct function call. We are allowed to panic within the same abstraction layer (application or in a library), but panic should not cause another application using it to abort, there should be a way to let the application recover from it and decide whether to cancel the operation or do other actions. If the mutable states are not shared and execution can be recorded, we can just restart the library after abort and resume to the previous state.
- nine_k 4y ago
  This description makes me immediately think of Erlang (and Elixir).
rapind 4y ago
I heartily recommend you take a look at Elm if you find this interesting.

tacotacotaco 4y ago

> A language's programs will (in practice) often be a reflection of what the language makes easy and what it makes hard… In industrial design this is called an affordance. The product is designed to encourage correct usage and make incorrect usage difficult. I would like it if more language designers will carefully consider their language’s features like this. The Elm language is a good example.

pca006132 4y ago

Ｉ think this may also be a good way to separate libraries from application code, by considering the library as another actor instead of a direct function call. We are allowed to panic within the same abstraction layer (application or in a library), but panic should not cause another application using it to abort, there should be a way to let the application recover from it and decide whether to cancel the operation or do other actions. If the mutable states are not shared and execution can be recorded, we can just restart the library after abort and resume to the previous state.

nine_k 4y ago
This description makes me immediately think of Erlang (and Elixir).

rapind 4y ago

I heartily recommend you take a look at Elm if you find this interesting.