7 ms·

Clojure hosted on Go is something that I really hope gets more attention. Clojure being built on top of Java is a fine decision, but I would love to use clojure

Clojure hosted on Go is something that I really hope gets more attention. Clojure being built on top of Java is a fine decision, but I would love to use clojure to compose the ever growing library of stable packages that exist in the Go ecosystem. other related packages: https://joker-lang.org/ https://joker-lang.org/ https://github.com/nooga/let-go https://github.com/nooga/let-go

vips7L 2y ago
Doesn’t the Java ecosystem have even more stable packages?
- packetlost 2y ago
  Maybe, but IME they tend to be lower quality than the Go ones. Java has some truly great libraries, but culturally has an entirely different approach to almost everything.
  - peterashford 2y ago
    As someone who has been working in Go for years, that's not been my experience
  - tombert 2y ago
    Any specific examples? The stuff I've used has been broadly better in JVM land than Go land, but I mostly work with Kafka stuff.
- xyproto 2y ago
  Stable, often overenigneered and often hard to upgrade when used as several dependencies together.
  - gf000 2y ago
    How does a less expressive language help with any of these? Also, I very much don't share your opinion based on experience, unless we are talking about straight up frameworks and not libraries.
    - 708145_ 2y ago
      A highly expressive language makes overengineering easier.
      - gf000 2y ago
        Java is definitely not even close to being "highly expressive". It has been a very simple language, and was always very conscious of remaining that with a slow, but well-thought-out evolution, learning from others' mistakes.
        agumonkey 2y ago
        i guess java confused verbosity with expressiveness
        gf000 2y ago
        Without entering the territory of flamewars, Go is objectively more verbose than Java, so I don't really see your point.
        aatd86 2y ago
        Does someone disagreeing with your statement make it not objective anymore? :o)
        agumonkey 2y ago
        Hmm maybe I'm too out of touch. You're talking about recent java (12+) vs go ? I stopped working in java so maybe I'm too bruised by the J2EE 5 era, but what I saw from Go was an order of magnitude less verbose than my memories of java.
        gf000 2y ago
        Java EE was/is a whole platform, framework, deployment model all in one. Also, most of the verbosity of that early version was very high flexibility (everything could be replaced) plus an XML-based configuration. I wouldn't really count XML in Java's verbosity, nor do I think that comparing it to vanilla Go is meaningful. For similarly scoped libraries Java is less verbose due to go's error handling being all over the place.
- 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 ago
    A 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 ago
      What'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 ago
        I used to try to build “lisp’y” wrappers. Misplaced esthetics.
throwaway894345 2y ago
I really like Go as well, but the JVM is a lot better at hosting languages than any interpreter implemented in Go. You will likely pay a significant performance cost even for a very optimized Go interpreter. I wish this were not the case.
iLemming 2y ago
My latest favorite kid on the block is nbb. The REPL spins up instantaneously, and you can use all Node packages, it requires virtually zero setup. But if I can rich out to Golang, why not? More Clojures is better. Imagine a single Polylith repo with blocks that talk to Node, JVM, Go, Python, etc.? Woah, that's sounds insanely cool, right?

vips7L 2y ago

Doesn’t the Java ecosystem have even more stable packages?

packetlost 2y ago
Maybe, but IME they tend to be lower quality than the Go ones. Java has some truly great libraries, but culturally has an entirely different approach to almost everything.
- peterashford 2y ago
  As someone who has been working in Go for years, that's not been my experience
- tombert 2y ago
  Any specific examples? The stuff I've used has been broadly better in JVM land than Go land, but I mostly work with Kafka stuff.
xyproto 2y ago
Stable, often overenigneered and often hard to upgrade when used as several dependencies together.
- gf000 2y ago
  How does a less expressive language help with any of these? Also, I very much don't share your opinion based on experience, unless we are talking about straight up frameworks and not libraries.
  - 708145_ 2y ago
    A highly expressive language makes overengineering easier.
    - gf000 2y ago
      Java is definitely not even close to being "highly expressive". It has been a very simple language, and was always very conscious of remaining that with a slow, but well-thought-out evolution, learning from others' mistakes.
      - agumonkey 2y ago
        i guess java confused verbosity with expressiveness
        gf000 2y ago
        Without entering the territory of flamewars, Go is objectively more verbose than Java, so I don't really see your point.
        aatd86 2y ago
        Does someone disagreeing with your statement make it not objective anymore? :o)
        agumonkey 2y ago
        Hmm maybe I'm too out of touch. You're talking about recent java (12+) vs go ? I stopped working in java so maybe I'm too bruised by the J2EE 5 era, but what I saw from Go was an order of magnitude less verbose than my memories of java.
        gf000 2y ago
        Java EE was/is a whole platform, framework, deployment model all in one. Also, most of the verbosity of that early version was very high flexibility (everything could be replaced) plus an XML-based configuration. I wouldn't really count XML in Java's verbosity, nor do I think that comparing it to vanilla Go is meaningful. For similarly scoped libraries Java is less verbose due to go's error handling being all over the place.
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 ago
  A 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 ago
    What'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 ago
      I used to try to build “lisp’y” wrappers. Misplaced esthetics.

throwaway894345 2y ago

I really like Go as well, but the JVM is a lot better at hosting languages than any interpreter implemented in Go. You will likely pay a significant performance cost even for a very optimized Go interpreter. I wish this were not the case.

iLemming 2y ago

My latest favorite kid on the block is nbb. The REPL spins up instantaneously, and you can use all Node packages, it requires virtually zero setup. But if I can rich out to Golang, why not? More Clojures is better. Imagine a single Polylith repo with blocks that talk to Node, JVM, Go, Python, etc.? Woah, that's sounds insanely cool, right?