Discussion

Unix Isn't for Agents

jaen: Might've fact-checked this article after letting Claude write it...Erlang processes are in no way what's commonly called "persistent" - there's no way to persist them automatically (ie. freeze to disk and wake later). It's even preferred to either use external databases like Mnesia or manually implement persistence in the actor itself for robustness.The only even slightly mainstream persistent environment is Smalltalk with its images.For Linux there's also CRIU, but that has quite a few caveats.If the definition of "persistent" is "processes run until they're done or they crash", well, pretty much everything fulfils that, so the distinction is meaningless.> "You can send messages to a process from a terminal, from another process, from a web socket, from anywhere."Also technically wrong. This only works if you have a cluster of erlang nodes already set up in full mesh mode. It's not auto-discoverable, scalable, P2P or anything remotely like that. If you want that, it's outside the Erlang stdlib. Websockets etc. need to be manually proxied. There's no standard protocol, security boundary or anything...Ugh, actually I give up, there's too many mistakes to even go into.Final verdict: slop.

sergius: Unix is a base layer that provides enough abstractions to build services. Perhaps there are better abstractions if one looks at Plan 9... but that never took off unfortunately.What they want is a framework for persisting stuff... that is an application level service... go ahead and build one.

AreShoesFeet000: It sounds like people are being paid to push Erlang for agentic stuff. Cool story, but if I end up feeling like I need to “return to the 20th century” for abstractions, I’ll just use Lisp.

jauntywundrkind: Coincidentally, I noticed yesterday that Deciduous (a tool, skill-set, & program for LLMs to look at git history & build decision graphs) opened a draft to switch to Elixer, from rust. https://github.com/notactuallytreyanastasio/deciduous/pull/1...OTP Supervision is listed as one of the primary reasons for this switch. I also noticed: 15,441 lines added / 109,254 lines removed !There's definitely a bunch of agent related thing out there they have various daemons they kick off. I feel like often this is over some kind of fancy protocol, where there is still a somewhat thick CLI client. I wanted to play around with making a very thin CLI (and with a prefork model in rust) and wrote a little sample repo for myself to explore the idea: it just passes the stdin/stdout/stderr directly to the daemon, for it process with. https://tangled.org/jauntywk.bsky.social/pfd

jauntywundrkind: Agreed!Clients and daemons end up relying of fairly heavyweight protocols to chat (dbus, various DB protocols, grpc), and it feels cumbersome, and means leaving the native paradigm of the shell anyways when we drift into these protocols.Its not an agent problem specifically: this is a meta-crisis. There is an ongoing meta-thread about "the tyranny of the application", that it contains its process and is bad at sharing, that the data is the thing and multiple tools ought be able to coordinate around the data. This extends to CLI programs too! They too are really not good at making the state they hold (as both a Model of the data and as a ViewModel over their interfaces) available, extropic.Plan9 is as close as we've gotten to addressing this. We could implement more 9p protocol or Filesystems in UserSpacE (FUSE) programs to make their state easily available.Turso has an interesting agentfs, which is just a filesystem that happens to be on Turso, their sqlite compatible rust database. This is a bit generic of a filesystem, isn't very application specific. But it is intended for agent use, and it uses FUSE, so is definitely notable here. It would be neat to see this adapted to expose more interesting application specific payloads. Their intro post: The Missing Abstraction for AI Agents: The Agent Filesystem https://turso.tech/blog/agentfs https://turso.tech/blog/agentfs-fuse(The sqlite compatible backing here would also allow for interesting SQL based processing of the state too, which could be a bonus; you now have dual interfaces, fs or DB, for the same data)