I've been working on an #OS idea I've had for a long time. The idea is a mix of #smalltalk, #lisp machines and #Elm. Instead of a filesystem you get a simple transactional KV store. Processes are actors, but they only exist as state in the DB + an address registry. If they havent received a message they do not use memory or CPU. Actors are written in a typed lisp language. It's easy to create programs that store state and where that state persists across reboots. Every program is like that by default. The system is based on a very simple set of capabilities, only two types exist: an actor address and a hash in the content addressable store which gives you read access. With this plus the sbility to spawn new actors with arbitrary s-expr allows you to spawn actors that refine the set of capabilities in arbitrary code defined ways without having to create more granular capabilities. #osdev
@dziban Very cool. I have worked on such things on the past. The current state of the art in research is what people are calling "durable execution", for instance in Postgres. There's also been some good work done on running fully Turing-complete code within the database context. Some things you mention are also related to serverless functions. I have realized that you can really use any programming language as long as you virtualize the external as internal (filesystem, processes, etc.)

@brandon Correct, a lot of my language research is about how pure state + update function languages have this idea of durable execution implicit without having to jump through hoops (like temporal) and the benefits that brings. The idea of Elm-like actors communicating with each other persistently as the fundamental process abstraction for an OS is appealing to me.

It seems to me like right now if you want persistence when building an app you are either stuck in "I want it very simple, I'll use a toml/json file somewhere in the file hierarchy and hope for the best" or I embed sqlite and save it somewhere in the file hierarchy.

I'm very interested in atomic storage being part of the OS, making it super easy to store data, persistently and safely with many different small composable programs that you can only access if given that capability.

@dziban
This sounds very much like something I'd be interested in