Live data from Hacker News

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

github.com

41–50 of 72 posts

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

#41
post #27

Earlier quoted context omitted.

i guess java confused verbosity with expressiveness

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.

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

#42
post #10

Earlier quoted context omitted.

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

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.

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.

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

#43

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…

Oh yeah I definitely lost an hour debugging why something doesn't work in ClojureScript: it turns out I used :refer rather than :refer-macro. It's still possible to use :refer, but it requires some changes to the library such as https://github.com/Engelberg/instaparse/commit/0cd039659dc76...

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

#44

I get "panic:" at the REPL once it loads. :( The implementation of the [HAMT][1]-based vector in Go is [interesting][2]. [1]: https://infoscience.epfl.ch/server/api/core/bitstreams/f66a3... [2]: https://github.com/glojurelang/glojure/blob/main/internal/pe...

[deleted]

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

#45
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.

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.

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

#46
post #40

Why not transpile to Go and then build a native executable?

Glojure author here. Transpiling to Go is definitely something I've considered — and am still considering! My current focus is on use cases that prioritize interactivity, which makes the existing interpreter-based approach a better fit for now. That said, transpiling parts of the system (especially the core libraries) to Go is a strong possibility down the road, particularly as a way to improve startup performance. After that, it could be made available as a public feature.

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

#47

I get "panic:" at the REPL once it loads. :( The implementation of the [HAMT][1]-based vector in Go is [interesting][2]. [1]: https://infoscience.epfl.ch/server/api/core/bitstreams/f66a3... [2]: https://github.com/glojurelang/glojure/blob/main/internal/pe...

Sorry to hear it's not working for you . Please feel free to file an issue on the repo with any relevant details! While I only work on Glojure sporadically at the moment, I really value feedback like this, and I'll prioritize investigating critical issues like it.

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

#48
post #16
post #14

Tangentially related clojure dialect compiling via C++ & LLVM: https://jank-lang.org/ jank has a progress page to give you an idea how much is implemented so far: https://jank-lang.org/progress/

Thanks for the shout out. :) It's always great to see more Clojure dialects. For those jankers wondering what Glojure means for Clojure on native, the main thing to note is that Glojure is an interpreter. No JIT or AOT compilation (right now). Looks like it's a great start for an interpreter, though. Not quite ready for prime time, given some of the todos in the code [0], but the structure of it looks quite intention…

Glojure author here! Your analysis is spot-on :). I'll definitely take a look at clojure.core-test. As components mature, I focus on improving compatibility by porting tests from Clojure [0], but they often require modifications to accommodate differences in the host language. As you noted, there are still several fundamental features missing — most notably some core data structures. That said, the implementation is robust enough to support another non-trivial hobby project [1].

A bit more detail on some of your observations:

> No JIT or AOT compilation (right now).

I do plan to implement AOT compilation eventually. JIT, however, is more complex. Go's "plugin" standard library [2] could serve as a mechanism, but its support is limited and not without issues [3].

> it looks like the analysis could be largely a port of tools.analyzer

Exactly! Another key implementation strategy has been the handling of clojure.core. Instead of reimplementing everything from scratch, the Clojure 1.11 core libraries are programmatically transformed to work with Go [4]. However, this approach has its downsides — many functions appear to be available but are non-functional because parts of their implementation haven't yet been adapted.

And by the way, impressive progress on Jank! I've been following it closely and really admire the work you're doing.

[0] https://github.com/clojure/clojure/tree/master/test/clojure/... [1] https://github.com/jfhamlin/muscrat [2] https://pkg.go.dev/plugin [3] https://github.com/golang/go/issues/19282 [4] https://github.com/glojurelang/glojure/tree/808165fdc7e65672...

Post reply on HN