announcements 2026-11-04

Hey folks, in support of the https://www.clojuriststogether.org/news/q3-2026-funding-announcement/, Eve 0.9 is out: one persistent data-structure implementation for eleven Clojure hosts, built on a global blob store - every value in 1 MB linear pages named by CID, written into the writer's own pages, and CAS'd at the atom root β€” so the same atom lives in memory, on disk, or across the network and only materializes the branches you actually touch. It turns your Clojure into a "cloud language" by letting you move parts of your application and your runtime into globally observable, persistent data. It basically takes the epochally coherent sharing idea in Clojure and makes it a network protocol: https://github.com/SeniorCareMarket/eve Eventually we'll be making this tech available to other languages outside of Clojure. But IMO those languages will just end up looking more and more like Clojure. Eve argues that the same things that makes Clojure better for in language concurrency also make things better for distributed systems - we just need to further embrace immutability and epochal persistence coordination and keep building on this architecture into the cloud. Datomic was one step in that direction but I think we can be taking things further, with an ecosystem of distributed systems that implement these architectural ideas. Fair warning - Eve is currently a very AI driven development project. As such, the bits are very pre-alpha and are not ready for production. Getting eve ready for human consumption will require lots of human effort from actual humans reading the actual code and ensuring that it solves actual human problems the way we want. I have plans to formalize "namespace-level human validation" policies at some point where, for some large point releases, all namespaces that changed since the last release must be eyeball-checked by a human before the next release. But that's only after the bits have started to settle, and we have more humans involved in the "eve standard." Basically, if a bot changes a human-validated ns, it invalidates the ns until the next major release, when it gets another human eye-ball validation check. Head on over to #C0AP53Z8WBG to get involved and learn more!

1
🫑 2
πŸŽ‰ 10

I appreciate the human effort that went into crafting this announcement! Will keep an eye on this, fingers crossed :)

🀞 1

Thanks for sharing your approach on human validation. I think it's good to talk about it in the community and share what we each are doing and why.

BTW I didn't mean to imply that all AI driven projects aren't yet ready for human consumption. Making them free of all defects is a very fine art though, and this repo has moved at a high velocity, so just full disclosure, we need a "burn in" period for these bits. I'd also like to bring in the new lean/proof tools and other verification tools folks are using to nail down AI behavior. But I'm a personal believer that nothing will ever beat the "eyeball check" validation, for the important stuff.

For what it’s worth, I didn't read your post as a statement against other AI projects. I appreciate you explaining your methods and rationale. I think that's positive discourse that benefits the community.

βž• 3

https://github.com/replikativ/ansatz/tree/main/modules/lean-jvm: run compiled Lean 4 functions on the JVM.

(require '[ansatz.lean.jvm :as lean] '[ :as io])
(with-open [rt (lean/open)
            in (io/input-stream "pricing.leanjvm")
            p  (lean/load-artifact rt in expected-manifest-sha256)]
  ((lean/function p "Pricing.discount") 10000 1500 1000))
;; => 1000
1. You prepare a Lean project during your build. 2. The JVM then loads the artifact and interprets it. 3. Values cross as plain Clojure data (integers, strings, vectors, maps, nil/`{:some v}`), and Lean can call your Clojure functions through typed bindings. Deployment needs no Lean installation. https://simm.is/blog/lean-on-the-jvm/

πŸŽ‰ 5

lean-clj: write functions and proofs in Lean 4, call them from Clojure on the JVM. https://github.com/conao3/lean-clj deflean checks embedded Lean (proofs included) at compile time, and a CLI compiles whole Lean modules into Clojure namespaces.

(deflean arith
  (def double [n Nat] Nat (+ n n))
  (theorem double_eq [n Nat] (= (double n) (* 2 n))
    (by (unfold double) omega)))

(double 21) ;=> 42
io.github.conao3/lean-clj {:git/tag "v0.1.0" :git/sha "aa1bdb5"} Early stage (Lean 4.35.0). Feedback welcome!

πŸ‘ 1

Hey @conao3, nice work! Seems we are interested in similar topics πŸ˜„. What are your goals for lean-clj?

wow! I overlooked your post! I’m recently getting started with lean, so this is very basic PoC to demonstrate to interact Clojure and Lean. I think Lean is good, but Clojure’s grammar is more friendly for me.

πŸ‘ 1

That's very cool! I am building theorem prover in Clojure (https://github.com/Flexiana/rainbow) and I have also Lean4 back and forward support. Maybe we could have a channel here for theorem proving.

Cool, thanks!