Hacker News Reader

Comment by Jeaye | Hacker News Reader

Once you learn Clojure's syntax and semantics, you're no longer bound to the JVM. There's ClojureScript (JS), ClojureCLR, ClojureDart, jank (C++), Basilisp (Python), babashka (SCI), and many others. This means that, if you don't know Java or don't like the JVM, you can likely use Clojure wherever you already feel most comfortable.

For the most part, any Clojure code which doesn't use host interop will work on all dialects. Clojure also has support for conditional code, depending on the current dialect.

This is one of Clojure's superpowers.

View on HN

As someone who loves Clojure, I wonder about the real portability across host languages. Do you have experience with any of these other dialects? (beyond the obvious CLJS & Babashka?)

I am developing a test suite for portability of clojure.core across dialects. You can find it here: https://github.com/jank-lang/clojure-test-suite

Currently, we have Clojure, ClojureScript, ClojureCLR, Babashka, Basilisp, Phel, and jank running the test suite.

I have only used Clojure, ClojureScript, and Babashka in production. But I am the creator of jank.

I’d like to say thanks for that - I’ve been using it on my IR version of joker: https://rcarmo.github.io/projects/go-joker/ and it’s been very helpful to pin down bugs.

I build and maintain Portal, which runs on multiple platforms including: Clojure, Babashka, ClojureCLR, ClojureScript, nbb, joyride, basilisp and soon jank. The main thing that's different per platform is the os/fs/http/ws libraries but the runtime state and serialization is all the same and reused across all platforms. Also, recently I was able to get most of Portal's reagent viewers, which were designed primarily to run in a browser via ClojureScript, running on the JVM for Server Side Rendering. Clojure is the most portable language I have ever used!

I am learning Clojure this week, and my test project is a calculator / unit convertor [1]. I wanted it to run in the CLI and on the web, so it targets several hosted platforms: Babashka / JVM / ClojureScript. It's a single code base written in cross platform .cljc files. I already have about 250 tests written for the abstract calculator API, run as a test matrix across platforms, so the project is already in a good place for testing a new runtime.

I just learned about basilisp from the parent comment, so I asked Claude to add Python support to the same .cljc files I have, and we finished the port in about 30mins, and then fixed Python specific test cases for another 30 mins, but now all of the existing tests are passing. That's impressive in several ways.

Portability is achieved by testing. You have to put the platforms you want to support into your test harness, and the earlier the better. A calculator is purely functional, so this is a fairly straight forward port and really easy to test for. I'm not sure about larger projects, but it seems like there is something seriously right about Clojure's design that makes this easy to do.

[1] https://github.com/EnigmaCurry/calc

for JS there is also Squint which is a light-weight ClojureScript dialect without the Google Closure Compiler

indeed, light-weight means you just add a <script> and you're off to the races.

There's also nbb if you're targeting node https://github.com/babashka/nbb

> babashka (SCI)

Correct me if I'm wrong, but isn't babashka's "host"... um.. "native", for lack of a better word? It's compiled with Graal VM native, no?

Yes, there is SCI (Small Clojure Interpreter) in the middle, but that's beside the point, no?

https://github.com/babashka/babashka

https://github.com/babashka/sci

Babashka's interop is with Java, since Babashka uses a Graal-compiled version of the JVM. It's still the JVM, just baked down.

This is different from interop with the native world. It's different from the host runtime actually being native, rather than a baked down version of a whole VM.

Graal's native images blur the line between the JVM and native, I would not say Babashka has a native runtime. Perhaps borkdude would disagree. Might be an interesting discussion.

Look at the latest babashka release https://github.com/babashka/babashka/releases/tag/v1.12.218

What do you see in Assets? Native executables, specific to an OS + CPU architecture combination, like Linux + AMD 64 or MacOS + AArch 64.

Reply on news.ycombinator.com