3 ms·
I think most Clojure implementations take the lesson from the original that to be embedded in a platform rich with mature libraries is a great strength, but are
by pxc 2y ago
I think most Clojure implementations take the lesson from the original that to be embedded in a platform rich with mature libraries is a great strength, but aren't dogmatic about some idea that only a few runtimes are worthy of such embedding. The idea is more 'make it practical to bring a Lisp to work and integrate it with your existing projects', rather than 'create one implementation to rule them all by choosing the biggest ecosystem to integrate with' (though a consideration aligned with the letter was doubtless a factor in the choice of platform for the first implementation).
So the thought is more like: because Go is popular, a good Clojure implemented in Go will let me bring all the Clojure goodies to many additional projects with tight integration for little fuss— not 'finally a big ecosystem, the JVM has no software'.
Another way to think about it is that different platforms often have their own 'killer libraries'. Maybe for working with some Docker or some IaC tools, a Go-hosted Clojure would be especially convenient, for example.
- mark_l_watson 2y agoA little off topic, but as someone who has occasionally used Clojure since Rich released a beta version (on many professional gigs, and to support examples in my Clojure AI book), I used to make such a mistake by writing wrappers in Clojure for Java libraries I used. A while back someone set me straight, and I no longer do that. So much better to call Java directly. Seeing the Glojure/Go interop examples reminded me of this.
- Capricorn2481 2y agoWhat's the practical difference? Aren't you doing the same java interop in your app that you would be doing in your wrapper?
- mark_l_watson 2y agoI used to try to build “lisp’y” wrappers. Misplaced esthetics.