From C++ to Clojure: Jank language promises best of both

As someone who might be in your target demographic in theory but not familiar with Clojure, what capabilities does Clojure itself offer as a language that a different mainstream scripting language doesn’t?

For example, I’ve always thought that the interesting part of Erlang is Beam & the uninteresting part was a niche language. Beam with JS as the language is much more approachable & leverages a rich existing ecosystem of tooling & libraries. Indeed, if you look at it the right way Cloudflare Workers is exactly that; isolated virtual processes within a single OS process that communicate with each other using a message based IPC & if they crash just the microservice is taken down & transparently relaunched.

So from that perspective, why Clojure instead of the same features on a different more popular language?

I can imagine Jank being incredible “glue” to start until it takes over by osmosis. (For c++ of course)

Maybe I should play some advent of code games with it to get comfy!

[dead]

I am wary of LSP. I should try LSP again using eastwood, which probably has its trade-offs. While I absolutely admire Borkdude's many gifts to the Clojure community, the lack of static analysis in clj-kondo is a non-starter for me -- macro support is painfully manual. Because of its speed, clj-kondo likely is more performant in an editor LSP context, but too opinionated for me.

I think Clojure has benefit way more from nRepl and everything in that ecosystem, than LSP and that newfangled stuff, at least my personal setup relies on nRepl and doesn't even use LSP afaik.

> Also: no one has managed to explain to me what makes emacs so uniquely capable of interacting with a running interpreter, despite this usually being the USP I hear for “needing” emacs when attempting to Lisp.

As an Emacs user that has to work in teams of non-Emacs users, the answer to this boils down to culture and ecosystem maturity.

Purely technically, there's nothing that Emacs allows me to do with REPL Driven Development that _couldn't _ be done in another editor. Practically? I still haven't been able to even get (sufficiently) started with any editor.

I often have to work on a Rails codebase that takes tens of seconds just to start. Dev cycles in the traditional Edit-Restart flow were so painful that I wished badly to burn this codebase down and rewrite it all in a language and style that supports a Lisp-style REPL. Then I discovered inf-ruby.el in Emacs. It allows me to just edit the code and reload only what's changed. It automatically inserts the correct `module Xyz; ...; end` etc. No more restarts.

I showed it to my coworkers. They shared the pain with restarts. And yet, to this day, none of them have an equivalent to inf-ruby in their editors.

inf-ruby.el is less than 1400 lines of code. It's easy enough to implement in Vim, IntelliJ, VS Code, anything really. But it exists only in Emacs, so far. Why? I'm sure because some Emacs user, once upon a time, wished similarly to have a more Lispy REPL for their Ruby dev work, and just built it. Because they were used to it, from having used Emacs or other Lisps with Emacs.

Compare that to when I first tried to support Common Lisp development on VS Code. A language that already has full support for REPL Driven Development with an interactive debugger built-in. Nope, we aren't gonna use any of that, because in VS Code land, we use LSP. A model that really only works for languages that can be statically analyzed. You want Go To Definition on a method that's included from a module and called on a receiver that's a dynamic variable? Well, sucks to be you, I guess.

So, while people make do with the severe limitations of Solargraph or Ruby-LSP, I use robe.el — which adds lisp style code intelligence by running inside your Ruby process — and get code intelligence that actually works with a language as dynamic as Ruby. Again, robe.el was just there for me to use. Again, there's nothing about Emacs that makes robe.el possible in Emacs but not in other editors. Again, there's no equivalent to it (that I've found) in the ecosystems of other editors.

As the guy building jank, I agree with you about emacs, chords, etc. I'm a vimmer and I can tell you that Clojure is superb in Vim land (Conjure), VS Code land (Calva), Emacs land (??? some major mode), and IntelliJ land (Cursive).

The proper answer for Lisps should be use Allegro or LispWorks, which actually provide a full blown environment as Lisp environments of by gone eras.

Does vim display inline graphics in a repl, with editing capabilities?

This is one of the basic features of classical graphical Lisp environments from the 1980's, IPython and Jupyter notebooks, or better, Mathematica are only building upon this.

Emacs and vim are not quite at the same experience level.

> what makes emacs so uniquely capable

Emacs is easily programmable (and in lisp), more unixy than modern Linux, like a whole operating system. Lispers make tools for it because it's very easy for them. Lisp tools have been far advanced of others; LSP wasn't initially adopted in Lisp communities because better tools (swank) were already around.

I'm looking forward to it; being able to utilize C and C++ libraries directly from Clojure is something that I could see being pretty valuable.

I've been debating trying my hand at making a simple game engine...it would be great if I could use a Lisp to do it.

Slowness and bloat, plus the sheer dependency footprint.

That’s pretty cool. I would love to hear more about how this works.

In particular, whether it is restricted in practice to types that are std::is_trivially_relocatable.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p11...