The jank programming language

Overview & Goals

  • Jank is positioned as “Clojure on LLVM” with seamless C++ interop, nREPL, JIT, and dynamic redefinition, aiming to be a drop‑in replacement for “pure Clojure” code (no JVM interop).
  • Not yet released; first alpha is targeted for end of the year, with monthly dev updates.
  • Long‑term goals include optional static typing, pattern matching, value‑based errors, and richer error messages than Clojure’s.

Interop, Platforms & Tooling

  • Key differentiator is deep C++ interop: C++ is JIT‑compiled alongside Jank’s LLVM IR into a single module, enabling use of arbitrary C++ types/functions and stack‑allocated objects.
  • Plan to support embedding Jank as a shared library into existing native apps (including plug‑in style use).
  • Cross‑platform Clojure story: .clj/.cljs/.cljc files plus reader conditionals let libraries target multiple dialects; non‑interop Clojure libraries should generally run on Jank unchanged.
  • Initial audience is JVM‑Clojure devs who want native binaries; Windows and game‑dev use cases will be a later focus.
  • Tooling will lean on leiningen initially (new/run/test/package) with deps.edn support; a leaner Jank‑native build tool may come later.

Readability, Conciseness & REPL

  • Several comments praise Clojure’s (and thus Jank’s) terseness: complex transformations can be expressed in very dense code compared to Python/Elixir, especially using transducers and core sequence operations.
  • Others find Clojure hard to read: heavy use of parens, dense expressions, and implicit data shapes require REPL exploration, specs, or extensive comments.
  • Discussion around idioms (loop, partition, map/reduce) versus index‑based imperative code highlights a trade‑off between functional style, performance concerns, and immediate readability.
  • Some argue that effective Clojure/Jank reading essentially requires live REPL interaction; others see this as a strength.

Types, Specs & Future Language Features

  • There is extended debate about Rich Hickey’s critique of static types versus the practical benefits of types for readability, documentation, and refactoring.
  • Jank’s author explicitly diverges from a purely dynamic stance and is open to an opt‑in static “mode” (inspired by languages like Carp), so teams can prototype dynamically then lock down performance‑critical or correctness‑critical parts.
  • Specs/contracts (e.g., clojure.spec) are mentioned as an alternative or complement to types, especially in data‑heavy domains.

Performance, GC & Implementation Choices

  • Commenters request benchmarks comparing Jank (LLVM) with JVM Clojure; existing benchmarks exist but are somewhat stale due to rapid changes. Performance work is deferred until after correctness and feature parity.
  • Jank currently uses Boehm GC; there’s a stated plan to move to MMTK for modern, pluggable GC strategies.
  • Multi‑threading is not yet implemented but is considered non‑negotiable given Clojure’s STM and concurrency expectations; avoiding a Python‑style GIL is explicitly called out.
  • A long comment suggests a smaller self‑hosting core compiled via C to reduce complexity; Jank’s author rejects this as incompatible with goals of maximal performance, deep C++ interop, and being an embeddable C++ library built directly on LLVM/Clang.

Naming & Adoption Concerns

  • The name “Jank” triggers a substantial sub‑thread: some like the playful, memorable quality; others note strong negative connotations (“janky” = broken/cheap) and fear it will hurt enterprise adoption or be used as an easy excuse to block it.
  • Comparisons are made to names like Git, Slack, Rust, GIMP, Nimrod; some argue names can be overcome, others stress that early‑stage adoption in conservative orgs is very sensitive to branding.
  • An April‑Fools‑style “renaming” post is linked, suggesting the name debate is at least partly embraced humorously.

Memory Management & Native Focus

  • Jank is GC’d like Clojure; most values are managed by the GC, but C++ interop allows manual memory management and stack allocation when desired.
  • Compared with prior LLVM‑Lisps (e.g., Clasp), commenters worry about stagnation and compile times; current Jank compiler builds quickly, but big‑project compile performance remains to be proven.

Clojure Ecosystem & Interest

  • Some see Clojure’s momentum as having stalled and hope Jank can revitalize interest by removing the JVM barrier.
  • Others note that Clojure remains active, pays well, and is still used in industry, though not mainstream.
  • Related languages like Janet, Rhombus, YAMLScript, and Carp are mentioned as points on the design spectrum (native, Clojure‑inspired, typed, or whitespace‑oriented Lisps).