Clojurians Log v2

cc @kimo741

Yes exactly

simply having EDN at hand seems like it would be incredible. As I write myself guile snippets I can't help but think it could be even simpler with Babashka

I keep imagining re-plumbing unix with edn as the communication basis. No more text config files just /etc/fstab.edn.

Maybe get rid of files too, though. Just use facts

datomic at the center?

or maybe datalevin, it's open source, but it doesn't have history though, which is kinda important for stuff like nix/guix

Yes, I've seen a few recent projects/blogposts along these lines...

that reminds me of Hydra somewhat, a research OS that used contracts and interfaces rather than files/namespaces

https://tangrammer.codeberg.page/on-the-clojure-move/output/posts/difference-trust.html

Datahike

@me1445 mentioned this to me as well... seems fascinating https://www.unison-lang.org/

I wonder if guix could be straight-up translated into a dialect like babashka, then could we use such a working system as a comprehensive test harness. Then, gradually evolve the substrate (i.e. the actual operating system that guix materializes) into something simpler.

I haven't looked too deeply into datahike. Do you see specific advantages?

Hydra, hmm. https://en.wikipedia.org/wiki/Hydra_(operating_system)

From my POV it's a Datalevin competitor but @whilo is super ingenious with all the tooling and ecosystem he's built around it, I imagine both have their uses

I used datahike with s3 for a lightweight metadata governance project, was wonderful

big fan of datalog and hitchhiker trees now

no connection overhead, no object overhead, mapped memory files, distributed index space, can pick up new index nodes on next read etc, branching data of course

I think very similar to the other fact stores but felt very light and fit in AWS lambda which I liked at the time

@kimo741 I also looked into Unison when working on the current replikativ stack, a lot of the principles are shared (I work in this direction with replikativ since 2013 after all). It might be possible to modify sci's environment model to deploy code via https://github.com/replikativ/hasch into content-addressable functions in a similar spirit (e.g. by making var names hash/commit-id scoped). I have not explored this yet, but I think it is an interesting direction to explore. Clojure's REPL semantics are somewhat different though, it is intentionally mutable and flexible to provide the dynamism to modify and mess around while building. But I think both could be unified if state is isolated and can be versioned.