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 intentional. Based on some of the code [1], it looks like the analysis could be largely a port of tools.analyzer, which is honestly a smart way to do it.
To the author, you may be interested in the clojure.core-test intitiative [2]. I'm aiming to get a good test suite for all Clojure dialects.
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.
With the three mentees I have, plus my own tasks cruising along, the best way people can help is to build up interest and visibility in jank. Follow, repost, share, like, etc. Once jank is released, I want to make the largest splash we can.
If you have the financial means to sponsor my work, that also helps. I'm quitting my job at EA in January to focus on jank full-time for 2025 and I'd really like to secure some form of stability in terms of funding by the end of 2025.
Often times, when people learn Clojure, they are also learning functional programming and lisp and data-oriented programming and interactive programming all at once. Writing Clojure requires a shift in perspective, coming from the imperative and object-oriented paradigms, and without that shift, even basic programs can seem impossible to build. This shift was very difficult for me, coming from C/C++/C#/Rust, and I've spoken with many others who've felt the same. I suspect, when you talk about hitting walls due to state, it's due to that perspective shift not being complete.
Does that mean I'm saying Clojure is the best lang for everyone and it's their fault if they don't get it yet? No, certainly not. We need to do better with that, in the Clojure world, to make that bridge easier to cross. But, having fought my way across that bridge, I can confidently say that mutable state is no problem in Clojure. We have first-class support for it and that support is thread-safe by default. Unlike something like Haskell, effects aren't scary and don't need to be wrapped. They can be adhoc.
jank inherits all of this and just brings it to the native world. That means lighter binaries, faster startup, and easier interop with native libs. Aside from that, it's Clojure.
I may be biased, having built a career in game dev, but I would love to see people developing games using a REPL. Many games these days use Lua or similar for scripting logic, since it doesn't need to be written in C++, it can change at runtime, and it's reasonably fast. jank is all of those things, too! I think, if we can get jank into Unreal Engine, Unity, Godot, etc so that people can use their existing tool set, write functional code, and use interactive programming, it could be a game changer for game dev.
Another great use case, I think, is desktop GUI dev. Outside of Humble UI, which is still very new, Clojure's GUI story has been quite bad. The native world has all sorts of GUI options though and jank will be introducing them to Clojurists.
I think jank will be a good option for anyone who wants to use certain native libraries along with their Clojure programming. Jack Rusher, for instance, has said there are native graphics libs he'd love to use and jank is a promising way to do that.
Finally, I aim to provide a cargo-like experience (if you're familiar with Rust) for jank. This should make building native apps easy. As I alluded to in my post, building C and C++ apps is a pretty terrible experience. If jank can make that twice as easy, for example, it could be that native devs end up preferring it as their project baseline. Since jank allows for arbitrary C++ to be included alongside the jank sources, and required as though it's a Clojure namespace, it actually ends up being a pretty sane way to write programs which involve a lot of C++.
With all of that said, I don't imagine I'll be working on anything other thank jank for quite some time. I think of these mainly as things I'm excited to see others do. :)
jank is not easy to use yet. Removing vcpkg and the PCHs certainly helps with compilability, but with jank still being pre-alpha, it takes an adventurous spirit to get it going. Hang tight and we'll have binary releases coming next year!
> But again, Jank is not clojure .. just clojure-like, or so it seem
jank is Clojure. If it works on Clojure JVM and it works on ClojureScript, it should generally work on jank. Clojure doesn't have a language specification, but the community knows what a proper Clojure should feel like. Strong Clojure compatibility means anything outside of interop should just work. Naturally, interop on Clojure is very host-specific; Clojure JVM does one thing, ClojureScript does another, Clojure CLR does a third thing.
> That being said, what would be the benefits of a native clojure, you have common-lips and guile if you want native
At this point, we'd be discussing the benefits of Clojure over CL and Guile, which ends up being a different discussion. jank is for Clojure devs who want a native host and good native interop. It's also for native devs who want to introduce interactive programming and FP into their systems.
I looked at github and came away with the impression it's very much still a work in progress, but you seem to imply it's closer to being complete?
Does nrepl work well? Can I just load a relatively arbitrary cljc file?
This discussion made me check it out as I'd like to use it in conjunction with some C++ files/libs, but looking at the project left me really quite unsure as to it's current state.
jank is still under heavy development. It is not released yet. A lot of features are working, or complete, but the language is at least several months out from being alpha released.
Yes! Since jank is using LLVM, AOT compiled jank programs have a path to WASM. This isn't a primary goal for jank, but it's one we can definitely pursue once jank's Clojure parity and general dev UX has been established.
Not production ready. Not very usable right now. I need several more months to improve the tooling, error handling, and general compilation functionality. Stay tuned!
This is a great suggestion. I've been doing some research on Mojo, but didn't realize MLIR was the recommended approach going forward. I'll look more into this. Codegen is pretty straightforward, from jank's AST, just using LLVM's IRBuilder, so I'd expect migrating to a superset shouldn't be an issue.
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 intentional. Based on some of the code [1], it looks like the analysis could be largely a port of tools.analyzer, which is honestly a smart way to do it.
To the author, you may be interested in the clojure.core-test intitiative [2]. I'm aiming to get a good test suite for all Clojure dialects.
0: https://github.com/glojurelang/glojure/blob/e54deb6597ceafd3...
1: https://github.com/glojurelang/glojure/blob/e54deb6597ceafd3...
2: https://github.com/jank-lang/clojure.core-test
reply