Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Glojure: Clojure interpreter hosted on Go, with extensible interop support

github.com

Post reply on HN
Print view View original

51–60 of 72 posts

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#51

Post by pxc »

vips7L wrote: post #10
breadchris wrote: post #2

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://github.com/nooga/let-go

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

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.

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#52

Post by iLemming »

breadchris wrote: post #2

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://github.com/nooga/let-go

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?

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#54

Post by mark_l_watson »

pxc wrote: post #51
vips7L wrote: post #10

Earlier quoted context omitted.

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

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 t…

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.

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#55

Post by iLemming »

ValentinA23 wrote: post #32

Something I find problematic about the various implementations of Clojure is the lack of specs to determine a common ground. Clojurescript doesn't use the same conventions in import/require statements: you're supposed to import macros using :require-macros or :refer-macros (I'm not even sure anymore). Conversely, `:refer :all` was banned in a prescriptivist attempt at fixing Clojure "mistakes", the rationale behind t…

Legit complaint, can't really argue, yet, at the same time, using various Clojure dialects and Clojure-like Fennel requires so much less mental overhead. Even switching between Javascript and Typescript is not at the same level of unsophistication. I feel biased, but targeting JVM, Node, Browser, Bash, Lua, and now Go using a single set of idioms and patterns feels so much nicer and less frustrating. Even with all the little quirks and differences.

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#57

Post by vips7L »

agumonkey wrote: post #41
gf000 wrote: post #27

Earlier quoted context omitted.

Without entering the territory of flamewars, Go is objectively more verbose than Java, so I don't really see your point.

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.

Please don’t take this rudely. But if you haven’t used a language or looked into in over a decade perhaps you shouldn’t comment on it?

That being said you should really check out how streams, records, switch expressions, pattern matching and all of the recent additions in the last 5 years have made Java a magnitude less verbose than Go.

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#58

Post by j12a »

iLemming wrote: post #55
ValentinA23 wrote: post #32

Something I find problematic about the various implementations of Clojure is the lack of specs to determine a common ground. Clojurescript doesn't use the same conventions in import/require statements: you're supposed to import macros using :require-macros or :refer-macros (I'm not even sure anymore). Conversely, `:refer :all` was banned in a prescriptivist attempt at fixing Clojure "mistakes", the rationale behind t…

Legit complaint, can't really argue, yet, at the same time, using various Clojure dialects and Clojure-like Fennel requires so much less mental overhead. Even switching between Javascript and Typescript is not at the same level of unsophistication. I feel biased, but targeting JVM, Node, Browser, Bash, Lua, and now Go using a single set of idioms and patterns feels so much nicer and less frustrating. Even with all th…

Include another Clojure-like Lisp for PHP https://phel-lang.org/ that you can make e.g. WordPress plugins with, hehe.

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#59

Post by agumonkey »

vips7L wrote: post #57
agumonkey wrote: post #41

Earlier quoted context omitted.

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.

Please don’t take this rudely. But if you haven’t used a language or looked into in over a decade perhaps you shouldn’t comment on it? That being said you should really check out how streams, records, switch expressions, pattern matching and all of the recent additions in the last 5 years have made Java a magnitude less verbose than Go.

Few factors:

- a ton of java is still legacy, ask works with java 7 vs java 17 and enjoy the laugh

- I assumed java culture was still too rotten by its roots. I've used streams but whenever I have to import BiFunction I feel very sad.

on the other side, the few go code I've seen was always very concise, or even when the code base wasn't very well designed it was, at worst, still below java

Re: Glojure: Clojure interpreter hosted on Go, with extensible interop support

#60

Post by Capricorn2481 »

mark_l_watson wrote: post #54
pxc wrote: post #51

Earlier quoted context omitted.

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 t…

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…

What's the practical difference? Aren't you doing the same java interop in your app that you would be doing in your wrapper?
Post reply on HN