Hacker News Reader

Comment by packetlost | Hacker News Reader

I really wish there was a Clojure-like Lisp that wasn't married to the JVM. Yes, I know there are a few, but nothing compiled :(

View on HN

Check out https://ferret-lang.org? Mostly Clojure syntax (files are .clj) but reduces to C++. Seems to be mostly for embedded/microcontroller applications, Arduino, raspberry etc. Doesn't depend on the stdlib and can run with or without a GC and in as little as 2k of RAM apparently, which is pretty neat!

Color me intrigued.

Babashka is Clojure running natively. It uses a simplified version of the Clojure runtime compiled to native code. No JVMs involved at runtime.

https://babashka.org/

Babashka is interpreted, though (with SCI), so it doesn’t quite meet the GP’s dream.

Good point.

Alternative is to compile your Clj uberjar using GraalVM. Here's a project to document how to do that and which common libraries are compilable:

https://github.com/clj-easy/graalvm-clojure

If you have it working in babashka though, it means it can also be used with Clojure and compiled to native using GraalVM. So anything that runs in babashka can be compiled to native as well. At least in theory.

https://janet-lang.org/

Janet seems cool!

Why? Just curious. I've found the JVM to be surprisingly stable and great to work with.

I love Clojure but the JVM is admittedly resource hungry.

I haven't found that to be an issue. For small programs there's also babashka.

Super long startup times and large binary size are what turned me off. This is clojure specifically not jvm specific. I find the JVM to be fine, but when I looked for another lisp I did want one that was compiled just because it was easier to distribute my programs.

You can compile it to a native binary, then you get super fast startup times and small-ish binary sizes.

I invite you to try it. Put together a modest CLI that does SQLite, some network calls, and unzips files. ( https://github.com/djhaskin987/zinc ). Using native-image with any reasonable set of dependencies like this is *horrendous*. Just because you can doesn't mean it's tractable. I spent 10% of my time writing the tool and 90% of it trying to get it to compile. Absolutely the worst experience trying to get something to build in my life, and I'm a devops engineer. Building and shipping code is my thing.

Ya, I'm not going to disagree, it's not the nicest build pipeline.

That said, you can figure it out normally.

Using native dependencies will always be the hardest. I'd recommend first trying to use graalvm friendly libraries, and if not, libraries that are pure Java and don't have native dependencies.

For SQLite for example, you have to include the SQLite C driver, and that's where it gets a bit complicated.

See here for a demo build that includes SQLite: https://github.com/ericdallo/sqlite-graalvm-sample/tree/mast...

The most friendly way is to rely on this: https://github.com/clj-easy

It lists Clojure native image friendly libraries you can use. And it also includes some pre-configured dependencies you can depend on that will bring the correct build config.

Then just pretend like there are no other libraries yet for this "new" language. Or learn about the native image process more deeply and contribute to the effort to add easier support for more libraries.

Depending on what you're going for, you could use GraalVM.

Sure, but the real problem is you're tied to the JVM ecosystem of tooling to some extent

One persons problem is another persons… enormous stack of existing tooling. You’re not wrong, but the knife cuts both ways on that point.

It is ridiculously difficult to use native-image. The only one I know of to successfully pull this off in a broad wide-ranging program is the author of babashka, Michael Borkent. The man is a legend, and using his work I was able to get my program to run on Linux, but getting it to run Windows was a whole nother hurdle and I wasn't willing to continue. Keeping track of all of those jira issues and matching Clojure releases with native-image releases and getting all the configuration files right and writing the scripts that you need to write the configuration files, and then waiting 30 minutes for anything of value to compile, not really an ideal development cycle scenario.

tbh, it worked pretty easily under windows.

1. use vcvars64.bat, usually in ...\Community\Common7\Tools\vcvars64.bat or ...\Enterprise\VC\Auxiliary\Build\vcvars64.bat

2. lein uberjar

3. Setup GraalVM: set JAVA_HOME=C:\Program Files\GraalVM\graalvm-ce-java17-22.3.0

4. native-image --no-fallback -jar target\default+uberjar\clojuresque-0.1.0-SNAPSHOT-standalone.jar

(you have to tweak with the paths above, depending on your system.

The resulting executable isn't small, but it starts quickly and doesn't depend on anything on the system other than MS C-runtime redistributable.

Sure, sure, the base case is easy. I would be more impressed with an example that has datalevin or SQLite as a dependency, though. Also Cheshire and/or jetty. Real-world dependencies make it difficult.

https://github.com/carp-lang/Carp

Clojure like syntax, Rust like internals.

There's Cloture which is a partial implementation of Clojure on top of Common Lisp. Though it's unfinished and seemingly abandoned for now.

This isn't usable yet, but in active development by the author, and looks promising: https://jank-lang.org/

Clojurescript

Reply on news.ycombinator.com