Author here. let-go is a Clojure-like language implemented in pure Go. It is intended to be practically compatible with JVM Clojure where that makes sense, but it is not a drop-in replacement.
It currently ships as a roughly 10MB static binary and cold boots in about 7ms on my machine. In the benchmarks included in the repository, it is competitive with Babashka on some algorithmic workloads, while having a much smaller startup cost than JVM Clojure.
The project started in 2021 as an experiment in building a small embeddable Lisp with Clojure semantics and Go interoperability. Over time it grew into a compiler and stack VM with support for nREPL, AOT bytecode blobs, standalone binaries, WASM, and interop with Go functions, structs, and channels.
It does not load JARs, does not expose the Java APIs.
The main use cases I have in mind are embedded scripting in Go programs, CLIs, small servers, data processing tools, and self-contained binaries.
Great addition to the Clojure ecosystem, and well done on articulating where the runtime fits, I find it's often overlooked or unclear. Do you see the future direction to focus on size, performance or improved support for long term workloads?
Thanks! I think it already shines when it comes to small footprint and fast boot time. I would like to keep it this way and not bloat it up much more. I have some ideas on how to improve throughput while staying small: migration to a register VM, fused instructions, basic compiler optimizations. I want to avoid JITing to native code as this comes at a cost of enormous complexity.
[OP] nooga | 14 hours ago
Author here. let-go is a Clojure-like language implemented in pure Go. It is intended to be practically compatible with JVM Clojure where that makes sense, but it is not a drop-in replacement.
It currently ships as a roughly 10MB static binary and cold boots in about 7ms on my machine. In the benchmarks included in the repository, it is competitive with Babashka on some algorithmic workloads, while having a much smaller startup cost than JVM Clojure.
The project started in 2021 as an experiment in building a small embeddable Lisp with Clojure semantics and Go interoperability. Over time it grew into a compiler and stack VM with support for nREPL, AOT bytecode blobs, standalone binaries, WASM, and interop with Go functions, structs, and channels.
It does not load JARs, does not expose the Java APIs.
The main use cases I have in mind are embedded scripting in Go programs, CLIs, small servers, data processing tools, and self-contained binaries.
sebastien | 3 hours ago
Great addition to the Clojure ecosystem, and well done on articulating where the runtime fits, I find it's often overlooked or unclear. Do you see the future direction to focus on size, performance or improved support for long term workloads?
[OP] nooga | 10 minutes ago
Thanks! I think it already shines when it comes to small footprint and fast boot time. I would like to keep it this way and not bloat it up much more. I have some ideas on how to improve throughput while staying small: migration to a register VM, fused instructions, basic compiler optimizations. I want to avoid JITing to native code as this comes at a cost of enormous complexity.