3 ms·
Here we go again with the "any Lisp that isn't Clojure isn't practical" argument. I disagree. Guile and Racket are plenty practical, and both have dynamic FFI
by davexunit 11y ago
Here we go again with the "any Lisp that isn't Clojure isn't practical" argument. I disagree. Guile and Racket are plenty practical, and both have dynamic FFIs to any C library you want so I couldn't care less about using Java and its terrible VM boot time and build systems. I'm not interested in "good enough" when I've already been using something better for years.
- siavosh 11y agoCurious if you could tell us more about what you've worked on with Guile/Racket in a production environment?
- davexunit 11y agoI'm not the persuasive person that convince the bosses to use Scheme, so I don't have a triumphant success story, but some minor victories. I'm one of the core developers of GNU Guix (a package manager, distro, and associated set of tools) that recently was deployed successfully in a large production HPC cluster in Germany, which I think is a pretty nice achievement. At work, I use Guix and an init system called DMD (also written in Guile) a lot for development, and I'm trying to slowly work them into production via Docker. It's an uphill battle to advocate for something that isn't the status quo, so I'm proud of the little victories.
- cle 11y agoIf you build systems that are part of an existing ecosystem, specifically an ecosystem built on Java technologies, then Guile or Racket would be terrible choices.
- davexunit 11y agoSure, that's fair, and for that Clojure is a fine choice.
- akmiller 11y agoI'm a Clojure developer and I agree that people shouldn't use the argument that other Lisps aren't practical (I'm just happy people are using lisp based languages). The point we should make is that for any shop that's using the JVM or Javascript already it's easy to introduce Clojure/ClojureScript into that environment without a ton of risk.