4 ms·

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

by jfoutz 8y ago

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

slondr 8y ago
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.
- drcode 8y ago
  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)
- fiddlerwoaroof 8y ago
  sbcl also has the ability to statically link all your C dependencies using CFFI’s STATIC-IMAGE-OP
  - lincpa 8y ago
    Clojure can also do it. Java Abstracted Foreign Function Layer https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi
    - fiddlerwoaroof 8y ago
      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.
protomyth 8y ago
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.
lincpa 8y ago
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
fulafel 8y ago
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.
- StreamBright 8y ago
  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.

by jfoutz 8y ago

slondr 8y ago

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.

drcode 8y ago
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)
fiddlerwoaroof 8y ago
sbcl also has the ability to statically link all your C dependencies using CFFI’s STATIC-IMAGE-OP
- lincpa 8y ago
  Clojure can also do it. Java Abstracted Foreign Function Layer https://github.com/jnr/jnr-ffi https://github.com/jnr/jnr-ffi
  - fiddlerwoaroof 8y ago
    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.

protomyth 8y ago

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.

lincpa 8y ago

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

fulafel 8y ago

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.

StreamBright 8y ago
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.