How innovative is Clojure as a Lisp dialect from Lisp expert's perspective?

Re:How innovative is Clojure as a Lisp dialect from Lisp exp... by slondr on Sunday January 06, 2019 @07:19PM (#18841696)

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.

[ Parent | on HN ]

Re:How innovative is Clojure as a Lisp dialect from Lisp exp... by drcode on Sunday January 06, 2019 @08:27PM (#18842031)

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)

[ Parent | on HN ]

Re:How innovative is Clojure as a Lisp dialect from Lisp exp... by fiddlerwoaroof on Sunday January 06, 2019 @08:28PM (#18842032)

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

[ Parent | on HN ]

Re:How innovative is Clojure as a Lisp dialect from Lisp exp... by lincpa on Monday January 07, 2019 @05:53AM (#18844254)

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

[ Parent | on HN ]

Re:How innovative is Clojure as a Lisp dialect from Lisp exp... by fiddlerwoaroof on Monday January 07, 2019 @02:15PM (#18848871)

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.

[ Parent | on HN ]