The jvm is really nice. Operationaly, it’s kind of a pain. You can upgrade the installation on bare metal, you can play the packer game and ship new vms, or you can have crazy fat docker containers. K8s can sort of deal with the vm model, but it’s beta.

Go is pretty nice in this regard. I should look into racket and chicken again for static binaries. I gotta say “from scratch “ is a fun way to start a dockerfile

If you want to write a program in a Lisp and ship it as a compiled binary, your best bet is to use Common Lisp and compile it with SBCL. A stripped SLAD binary will be way smaller with way less overhead then running a whole host of bytecode on a VM like Racket or Clojure.

But few people care about overhead or executable size much anymore, outside of embedded systems.

What most people care about is computational performance, and clojure performs OK by this metric (certainly SBCL can still beat it in many use cases on this metric as well, but often only by a modest margin)

sbcl also has the ability to statically link all your C dependencies using CFFI’s STATIC-IMAGE-OP

Clojure can also do it. Java Abstracted Foreign Function Layer https://github.com/jnr/jnr-ffi

I don't think that's exactly the same: CFFI has the ability to bind C libraries with minimal boilerplate just like jnr-ffi does. But, in addition, with CFFI (and sbcl built with a particular set of flags) you can generate an CL image that only depends on GLIBC because you've statically linked all your .so dependencies into the resulting image.

If you are writing software in an enterprise then Java / JVM is a well understood quantity with a whole lot of deployment options. Being something that looks exactly like every other Java program from the point of view of those deploying it is a huge win.

Can you expand on the comment about Kubernetes and VMs?

I don't know much about Kubernetes but AFAIK people just put a jar file and JVM in the container image and run it just like any other server app. The jar files can get big (100+ MB) if you have lots of deps, but not to the extent that container image size would be problematic in normal server app environments.

Well JAR files are that big because many java devs import libraries that they never use and you end up with 100+ dependencies when you really need 10. Clojure (Maven) has a way of dealing with this using :exclusions. My typical jar files are 10 - 50MB which are manageable today very well.

You can compile the Clojure project with graalvm, or you can compile the Clojure-clr project (or Clojure project translated by ikvm.net) with the .net core CoreRT

It's debatable how innovative that was because ABCL was running on the JVM before Clojure. Clojure was definitely marketed better, though.

+1 for mentioning Armed Bear Common Lisp. I usually use SBCL but ABCL is great when you need Java interop (I use it with DL4J).

I have used Clojure when requested by customers (about 18 months total) since its inception: I donated to Rich when he asked for community support because I liked the Common Lisp to Java bridge he wrote many years ago.

Clojure is a good language that has a uniform API for anything that is a sequence and I (usually) like working with immutable data.

That said, I enjoy CL and Scheme more.

Not marketing, just a bunch of different core ideas, immutable/concurrent first. It was a lot more attractive than yet another CL port.

There's been a few Lisps targeting JVM since early 2000s, back when JVM arguably had a lot larger mindshare.

Given the amount of embedded devices with a JVM running on them, and the OSes that have someone selling a JVM for them, I would say the mindshare is even bigger nowadays, just not hip as it once was.

Unless you count Dalvik, there's probably more embedded devices running Node than JVM nowadays. The share of Java related technology has definitely declined on most platforms.

SIM Cards, eletricity meters, Cisco phones, Ricoh printers, factory control systems, IoT gateways, BluRay players, there are tons of invisile JVMs running on the wild.

You could say that in 2003, and that would have been even more true. Especially about BluRay players ;)

My local library has started replacing DVDs with BluRay discs.