Clojurians Log v2
yamlscript 2026-09-15
This is fun:
$ curl -sL | ys -c -o 99-bottles
√ Compiled to native binary: '99-bottles' (1.2s)
$ ls -lh 99-bottles
-rwxr-xr-x 1 ingy ingy 18M Sep 15 09:58 99-bottles*
$ file 99-bottles
99-bottles: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, BuildID[sha1]=cf581d110be5a03d88e7ba933f6175ea82122e78, stripped
$ ./99-bottles 2
2 bottles of beer on the wall,
2 bottles of beer.
Take one down, pass it around.
1 bottle of beer on the wall.
1 bottle of beer on the wall,
1 bottle of beer.
Take one down, pass it around.
No more bottles of beer on the wall.
$ $ time ./99-bottles 1
1 bottle of beer on the wall,
1 bottle of beer.
Take one down, pass it around.
No more bottles of beer on the wall.
real 0m0.005s
Fast! This is the new toolchain based on Glojure, right?
Right
ys simply downloads gloat if needed and passes it the ys converted to clj
so everything I show with ys can also be done with clojure
Oh cool. So gloat does it.
one interesting this is that yamlscript ships to 32 langs. 29 of them are wrappers around libys.so. But Java, Clojure and Go don't need the shared lib. Java and Clojure can use the ys jars and Go uses the Go code from Glojure. So as we get more and more complete dialect languages, then each of them might be able to use their native code.
Oh interesting.
Honestly I guess Kotlin and Scala bindings don't need the shared lib because they are JVM based.
Also, ClojureCLR is quite mature.
I know what you mean, but in terms of the metrics that we want to start comparing by, I think it's quite lacking. @dmiller told me he thinks it probably only works with a couple maven libs. I suspect it works with more. But I'm also keen to help him make it more capable once we see the metrics.
But yeah I should see if the C# and F# YS bindings can do the same kind of shared lib avoidance. Good idea.
My statement is based on the fact that one line of interop that isn't conditionalized makes the code unloadable.
That's something that @yogthos and I have been thinking on in #C0B655S3R19
basically making JVM interop work across dialects.
I know some folks hate shims, but they do allow a lot of libraries to "just work" right now.
yeah they solve the chicken and egg problem so you don't have to rebuild the whole ecosystem from scratch
One could go a long way by designing libraries with all interop behind fences. But if you expose platform classes, there will be trouble. I have plenty of horror stories. I/O, threading, networking -- just mention them, watch for my facial tics.
oh there's no argument that it would be better if there was a Clojure layer that libraries used, but since we already have a lot of libraries in the wild, and it would be a Herculean effort to get them all to switch to using some new API, I think we are where we are now
Herclulean efforts are now doable in minutes 😄
even with LLMs, I would not want to take ownership of hundreds of libraries
For Glojure I had ai create Go versions on the most common Clojure libs (in minutes) https://github.com/gloathub/gojava Owenership is a state of mind 🙂
what's common really depends here, for example if you do web dev then stuff like Reitit and Hiccup is common, and these libraries continue to evolve as well
I'd much rather just use the original library and adapt the dialect to support it
I could translate a ton of libraries in days using AI. I cannot do any of that for the libraries I maintain in the Clojure repo.
Even though I find shimming useful, I do believe the goal is to shim as little as possible.
right, the more can be expressed in portable Clojure the better