Clojurians Log v2
announcements 2026-07-06
Some recent #lambdaisland releases:
https://github.com/lambdaisland/config v0.15.56
Config is a configuration library supporting config files, environment variables, Java system properties, XDG_DESKTOP file locations, command line flags (with https://github.com/lambdaisland/cli). It supports multiple profiles (dev/test/prod), and provides sensible defaults.
This version adds support for systemd-creds / $CREDENTIALS_DIRECTORY, for loading (encrypted) credentials when running under systemd.
https://github.com/lambdaisland/classpath v0.8.70
Classpath/classloader/deps.edn related utilities, and deps.edn hot-reloading.
This version switches from org.clojure/tools.deps.alpha to org.clojure/tools.deps. (Thanks @jbiserkov!)
https://github.com/lambdaisland/launchpad 0.50.226-alpha
Launchpad is a Clojure dev process launcher.
ā¢ Prevent overwriting js-package-dirs in shadow-cljs (Thanks @ovidiu.stoica1094!)
ā¢ Switch from org.clojure/tools.deps.alpha to org.clojure/tools.deps
https://github.com/babashka/sci: Configurable Clojure/Script interpreter suitable for scripting and Clojure DSLs SCI is used in https://github.com/babashka/babashka, https://github.com/babashka/nbb, https://github.com/nextjournal/clerk, https://github.com/BetterThanTomorrow/joyride/ and many https://github.com/babashka/sci#projects-using-sci projects. 0.14.54 ā¢ ClojureDart support. See thehttps://github.com/babashka/sci/blob/master/examples/cljd-flutter-repl. ā¢ Instance/static method+field overrides and`:closed`allowlist for`:classes`. Seehttps://github.com/babashka/sci/blob/master/doc/interop-control.md. ā¢ Improve performance for instance method interop: 1.6x on babashka. ā¢ Fix self-require (a namespace requiring itself, e.g. via`:require-macros`for its own macros) being reported as a cyclic load dependency Have fun making a scriptable mobile Flutter app š
awesome
Wow I think the instance override stuff gets you 90% of the way towards wrap-map-like overrides. Would be nice to take it to a wrap-class thing, like this, but for at runtime. Would need some runtime super object with all the methods and fields on it, I suppose š¤
wrap-map-like?
random map instance override tool thing I built https://github.com/johnmn3/wrap-map
Just because I knew I could... I only use it for pretty niche things
The runtime super object was already there in CLJS, it's called js ;)
{:classes {'js here-s-your-runtime-super-object}}js/whateveror didn't you mean the runtime global object?
Well, wrap map just wraps it, so it can unwrap it untouched
But for super object I just mean a "Object" thing that has all "built in" object methods and fields, so you can do the wrap map thing for any object type that is built in
Anyway, that's a side bar - this kind of overriding is permanent across the life of the runtime, right? Fairly different. Will be interesting for perf, I bet.
wow! this is so cool
you're on fire recently, borkdude
that was one of the last things in the pipeline before I write my Clojurists Together report for May and June ;)
clojure-lsp https://clojure-lsp.io/ 2026.07.06-14.34.19 released with a goal for this release: performance improvements! āØ ā¢ This release I decided to focus efforts on performance, tracking all progress in https://github.com/clojure-lsp/clojure-lsp/issues/2313, lots of details there, this affects all clojure projects, making clojure-lsp start faster and use less mem and cpu overall, here's TLDR: ā¦ Warm startup ~40% to 83% improvement: metabase went from 84s -> 14s ā¦ Cold startup cpu: ~33 to 39% improvement ā¦ Memory reduced ~51 to 60%: metbase went from 868mb -> 439mb ā¢ Lots of bumps, including automating clj-kondo bump when master commits lands. ā¢ Fix some cases where LSP cache write can goes wrong and project is never cached, (like metabase) ā¢ We now have performance tests to make sure clojure-lsp is not having regression in performance - Kudos @john.t.richardson.dev for the help! ā¢ We allow rename unqualified keywords now. https://github.com/clojure-lsp/clojure-lsp/issues/2139 Come to #lsp for more details Special thanks to #clj-together for the sponsorship! clojure-lsp š clojurists-together Happy coding!
@ericdallo Aside from the perf improvements in clj-kondo that @alexyakushev provided, were there also some done in lsp?
yes, a lot, check the linked issue
https://github.com/soulspace-org/overarch v0.42.0: Overarch provides a data model for the holistic description of a software system, opening multiple use cases on the model data. Supports C4 and UML diagram generation with PlantUML/GraphViz and template based artifact generation. Main updates: ā¢ enable building template library functions in clojure namespaces ā¢ new model elements for deployment, process and domain models See the release notes and change log for further information.
First big release of the https://www.flybot.sg/posts/21https://www.flybot.sg/posts/21 is out: v0.8.0. https://github.com/flybot-sg/magic compiles Clojure to .NET, so the same code runs on a server and inside a Unity game, including on iOS. Ramsey Nasser built and maintained it for close to a decade across six separate repos with no shared release. I gathered everything into one org at https://www.flybot.sg/posts/21: one repo, one version, with the tooling, drift check, CI, and release process. My thought process on making working on MAGIC, the rational behind the initiative: https://www.loicb.dev/blog/making-magic-stable. TLDR Why not just ClojureCLR? It generates IL at runtime, which mobile can't do (iOS forbids JIT, Android requires AOT, both via Unity's IL2CPP). MAGIC emits fully static IL, so it survives that path. That is the reason it exists. We used to have some workarounds in place in all our internal libs but not anymore) From v0.1.0 to v0.8.0: https://github.com/flybot-sg/magic/blob/develop/CHANGELOG.md Try it ā¢ https://github.com/flybot-sg/magic/tree/main/nostrand, a build-time CLI that compiles your Clojure to .NET DLLs, and also runs non-Unity CLR libs and their tests (Nostrand is Magic deps manager, it precedes tools.deps) ā¢ https://github.com/flybot-sg/magic/tree/main/magic-unity, a Unity (UPM) package that loads those DLLs at play time and runs the IL2CPP pre-processor so they survive ahead-of-time compilation to device. Resources Repo: https://github.com/flybot-sg/magic Announcement: https://www.flybot.sg/posts/21 Article on the rational behind each release: https://www.loicb.dev/blog/making-magic-stable Article on the CI side: https://www.loicb.dev/blog/drift-checks-for-a-self-hosting-compiler
I had high hopes for Arcadia so Iām excited to see this development!
For context for others, https://github.com/arcadia-unity/Arcadia was the framework to run Clojure in Unity (using ClojureCLR in the editor) while https://github.com/flybot-sg/magic was created for the export (build to mobile/console). I focused on Magic because it was what we need to compile our game logic lib to dotnet and we target all platforms, so I have not looked into Arcadia yet.
My goal now for the next release is to match better the tooling of @dmiller: at least the deps-clr.edn convention (I currently support a :clr alias in deps.edn option instead)
I hope to help and encourage people to port libs to the CLR and have a smooth way to compile clojure lib with ClojureCLR and Magic. As for now, aside from deps management / test runners, the main difference you'll hit porting a lib is the Clojure version (ClojureCLR tracks latest, Magic is on 1.10).
Also Unity is moving to CoreCLR so a big milestone would be to get rid of mono in favor of CoreCLR.
Thanks for the correction. I used arcadia in unity and knew I needed magic to have clojure on the iPhone but didn't understand well enough.
I look forward to taking a close look at your work. Ramsey and his work on Magic were an inspiration for me at a time when I needed some. I'm glad to see the work being continued.
I have been keeping in touch with Ramsey for almost as long as I joined my company and we also collaborated to have magic fixes and optimisation tweaks in 2022! I remembered emailing you back in 2021 to ask you questions about the DLR etc, time flies.
It is still my hope to incorporate the compiler innovations Magic introduced into mainline ClojureCLR, as in the ClojureCLR.Next project. I had to put that on the back burner in order to get some of the truly needful done, including cljr and the deps.edn work. I hope to get back to that work soon.