For a previous job I wrote a miniature/lightweight "actor system" with haskell threads and STM. Basically, each actor was represented by a thread, threads operated in a loop (like erlang actors), and threads had mailboxes implemented via STM primitives. It worked like a dream, and I've been wanting to write up a blog post about it for a good while now, but alas, there is always something else that needs to be done.
There is an idea that's been floating around in my head for some time now. I want to expose Unix ideas to the web era. If a "shell" were built to expose a lot of these things via the web (of course, only to authorized users), I could see an explosion in creativity.
This leads into the next thing, enabling people to have their own, independent servers. This is a massive topic, but basically, I'd like to see more ideas like sandstorm.io or cloudron.io take off.
I may be looking at this project as a place to start for my own code, and/or inspiration! Thanks.
I believe Sandstorm.io (and Cap'n Proto) at least adopts some of the ideas.
I suspect one of the things Sanndstorm did that probably caused it issues was was biting off too much, for example implementing its own linux containers system (I don't know what the details were, I just know that at the time, I was thinking "if it were me, I would just use docker.")
I actually had started working on modernizing the cloud haskell code, but just realized it was far more work than I had time to put towards it at that time. I'm trying to get some things complete so I can focus on some other things instead, such as contributing towards this =)
Assuming you are the same NicholasT, if you want I can share some of the code snippets that I used to implement what i'm talking about. I just know that I can't commit any significant time toward this right now though.
If you think of the Win32 API message loop then you can kind of think of each program and GUI as a mesh of independent actors with inboxes that communicate user GUI events to backend server actor that does CPU work or network work in the background.
I think this is an easy to understand architecture. If you think of it as MVC but what would be a method call in MVC is actually a cross thread event queue between server threads and client GUI threads.
Where GUIs get complicated and hard for me to read the code for is all the state management and complexity of components of the GUI itself. I wouldn't want to be tasked with implementing Qt or GTK.
The actor idea reminds me of programmatic "agents" or bots that work on your behalf on a schedule or in response to events (messages) such as Huginn.
The idea of plugging GUI components together so they interoperate is really interesting. COM and XPCOM is an example of this in practice for communication between applications (and the GUI) The DOM is an example of it too! You can insert arbitrary blocks in Notion or Obsidian or COM objects in Word documents.
https://github.com/huginn/huginn
I like the process viewer on the right hand side. Would be nice to be capable of visualisation what the applications are doing.
