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

Motivation and Advantages over JVM Clojure

• Main value props vs Clojure+GraalVM:
  • Native binaries without JVM, while retaining REPL/JIT–driven interactive development (which native-image largely loses).
  • Tight, “JVM-level” style interop with C++, including templates and RTTI, presented as unprecedented in the native space.
  • Lighter runtime than the JVM and easier access to native libraries and graphical toolkits.
• Several Clojure fans are excited to get Clojure semantics without “JVM madness” (startup, footprint, Java ecosystem overhead).

C++ / Native Interop and Game Development

• Strong interest from game devs:
  • Using Jank like Lua (embedded into engines) but with full C++ interop and real Lisp macros.
  • Potential fit with Unreal and native-style architectures; could serve as a “glue” layer that gradually takes over.
• Comparisons/alternatives:
  • Clasp (Common Lisp on LLVM with C++ interop), though limited Windows support is seen as a drawback.
  • Fennel (Lisp-on-Lua) and Janet (small Clojure-like Lisp) mentioned as lighter game‑scripting options.
  • Jank is framed as “actually Clojure,” unlike Clojure‑inspired languages such as Carp.

Tooling, Editors, and On‑Ramps

• Strong plea to invest early in tooling and non‑Emacs workflows (VS Code/Calva, Vim/Conjure, IntelliJ/Cursive) so C++ devs aren’t blocked by editor culture.
• Long subthread on Emacs vs other editors:
  • Consensus that REPL‑driven development is the key Lisp experience, not Emacs per se.
  • Emacs is seen as historically ahead because it’s easy to extend in Lisp and has a culture of deep REPL integration; others could match this but often don’t.
  • Discussion of LSP vs nREPL, clj‑kondo vs deeper static analysis, and how dynamic Lisps limit full static tooling.

Language Design: Ownership, Immutability, Concurrency

• One Rust‑oriented commenter argues that any new native Lisp should have ownership (Rust‑style) for reasoning about where values “are,” comparing it to the leap from dynamic to lexical scoping.
• Others counter that Clojure’s immutability and STM already provide strong guarantees; a detailed exchange explores:
  • How ownership models give syntactic guarantees about moves/borrows and can subsume some STM use cases.
  • How persistent immutable data and ownership can complement each other for performance (e.g., automatic transientification).
• No consensus; Jank is currently described as staying close to Clojure’s model.

GC, Performance, and Runtime

• Jank is garbage‑collected; currently uses Boehm, with plans to move to a more competitive GC (MMTK + Immix mentioned).
• Some worry about losing the JVM’s highly tuned GC; others note that native plus modern GC may be “good enough,” especially for games and GUIs.
• Perception of JVM as “slow and bloated” is challenged by others who point out its performance advantages over many alternatives.

Platforms, Ecosystem, and Status

• Mobile/iOS use case: author states Jank should be embeddable into Swift/iOS apps, with REPL for dev and AOT‑only for release (due to Apple’s JIT restrictions), thanks to LLVM.
• Current ecosystem is minimal; libraries are not really there yet and the language doesn’t fully implement Clojure.
• Interest in using Jank for native GUI apps, data‑heavy/scientific code (by analogy with Clasp), and scripting in existing C++ codebases.
• “Seamless C++ interop” is repeatedly highlighted but details are deferred; even sympathetic readers flag it as currently “unprecedented” and want more technical explanation.

Overall Sentiment

• Strong enthusiasm from Clojure users who dislike the JVM and from native/game developers intrigued by tight C+++Lisp integration.
• Healthy skepticism around:
  • Complexity and promises of truly seamless C++ interop.
  • Lack of ownership model for some Rust‑aligned developers.
  • Tooling maturity and the need for good first‑time experience.
• Many commenters say they’ll “keep an eye on it” and test it once a usable release and tooling appear.