DEV Community: clojure

Leiningen — Complete Tutorial & Best Practices

ivan.gavlik — Sun, 12 Apr 2026 11:23:33 +0000

Leiningen is the build tool and project manager for Clojure. Think of it
like npm (Node), Maven (Java), or pip (Python) — but designed around
Clojure's philosophy.

What Leiningen Does

Creates and scaffolds projects
Manages dependencies (from Clojars + Maven Central)
Runs REPLs, tests, and builds
Compiles and packages your app (JAR/uberjar)
Runs custom tasks via plugins
Manages profiles (dev/test/prod configs)

Project Structure
my-app/
├── project.clj ← The heart: dependencies, config, build
├── src/
│ └── my_app/
│ └── core.clj ← Main namespace (note: _ not - in folders)
├── test/
│ └── my_app/
│ └── core_test.clj
├── resources/ ← Static files, config, assets
├── target/ ← Compiled output (git-ignore this)
└── README.md

Note: Clojure namespaces use - (hyphens), but folder/file names use _ (underscores). my-app.core → src/my_app/core.clj

project.clj

  (defproject my-app "0.1.0-SNAPSHOT"
    :description "What this project does"
    :url "https://github.com/you/my-app"
    :license {:name "MIT"}

    ;; Dependencies: [group/artifact "version"]
    :dependencies [[org.clojure/clojure "1.12.0"]
                   [ring/ring-core "1.12.0"]
                   [hiccup "2.0.0-RC3"]]

    ;; Entry point for `lein run`
    :main my-app.core

    ;; Source paths
    :source-paths ["src"]
    :test-paths   ["test"]
    :resource-paths ["resources"]

    ;; AOT compile specific namespaces (needed for uberjar)
    :aot [my-app.core]

    ;; Profiles: override config per environment
    :profiles
    {:dev  {:dependencies [[ring/ring-mock "0.4.0"]]}
     :prod {:aot :all}
     :uberjar {:aot :all :omit-source true}})

Real world Example

Shows how do declare dependencies, plugins on project and profil level plus advanced usages of aliases

(defproject ebp-be "0.1.0-SNAPSHOT"
  :description "Backend project for Event Booking Platform."
  :url "https://github.com/IvanGavlik/ebp"
  :license {:name "MIT"}

  :dependencies [[org.clojure/clojure "1.11.3"]
                 [ring/ring-core "1.12.1"]
                 [ring/ring-jetty-adapter "1.12.1"]
                 [ring/ring-json "0.5.1"]
                 [compojure "1.7.1"]]

  ;; project level plugins
  :plugins [[lein-ring "0.12.6"]
            [lein-shell "0.5.0"]]

  ;; lein-ring plugin config - points to handler
  :ring {:handler ebp.handler/app
         :port 3000
         :auto-reload? true
         :reload-paths ["src"]
         :init ebp.handler/app-init
         :destroy ebp.handler/app-destroy
         :open-browser? true
         :war {:name "ebp-be"}}

  ;; entry point
  :main ebp.core

  :source-paths ["src"]
  :test-paths ["test"]
  :resource-paths ["resources"]

  :uberjar-name "ebp-be.jar"
  :profiles {:dev {:dependencies [[ring/ring-mock "0.6.2"]]
                   :plugins [[lein-ancient "0.7.0"]
                             [lein-cljfmt "0.9.2"]
                             [lein-kibit "0.1.11"]
                             [jonase/eastwood "1.4.3"]
                             [com.jakemccrary/lein-test-refresh "0.26.0"]]
                   ;; lein-ancient plugin config
                   :ancient {:check-clojure? true
                             :allow-snapshots? false
                             :allow-qualified? false}
                   :cljfmt {:indentation? true
                            :remove-trailing-whitespace? true
                            :insert-missing-whitespace? true
                            :remove-surrounding-whitespace? true}
                   :eastwood {:linters [:all]}
                   :test-refresh {:changes-only false}}
             ;; production build
             :uberjar {:aot :all :omit-source true}}
  :aliases {"dev" ["do"
                   ["shell" "cmd" "/c" "start" "cmd" "/k" "lein" "with-profile"
                    "dev" "ring" "server-headless"]
                   ["shell" "cmd" "/c" "start" "cmd" "/k" "lein" "with-profile"
                    "dev" "test-refresh"]
                   ["with-profile" "dev" "repl"]]
            "code-quality" ["with-profile" "dev" "do"
                            "cljfmt"  "fix,"
                            "eastwood,"
                            "kibit,"
                            "test,"
                            ;"ancient" ":all" ":profiles" does not work on windows
                            ]
            "ci"      ["do"
                       "clean,"
                       "cljfmt"  "check,"
                       "eastwood,"
                       "test,"
                       "uberjar"]})

Full source code here

Explanation of each of the sections

Profiles

You can put inside a profile almost anything that goes in project.clj at the top level:

  :profiles
  {:dev
    {:dependencies   [...]   ; extra deps for this profile
     :plugins        [...]   ; extra plugins
     :source-paths   [...]   ; extra source dirs
     :resource-paths [...]   ; extra resource dirs
     :env            {...]   ; env vars (needs lein-environ)
     :jvm-opts       [...]   ; JVM flags
     :main           ...     ; override entry point
     :aot            [...]}} ; override AOT

Activate a profile:
lein with-profile prod run
lein with-profile dev,test test # multiple profiles

Profiles merge, with later ones winning. :dev is active by default in most commands.

Common Patterns

Separate DB per environment

  :profiles
  {:dev  {:env {:db "jdbc:postgresql://localhost/app_dev"}}
   :test {:env {:db "jdbc:postgresql://localhost/app_test"}}}

Dev-only tools that don't ship

  :profiles
  {:dev {:dependencies [[clj-reload "0.7.0"]
                        [eftest "0.6.0"]]
         :plugins [[lein-cljfmt "0.9.2"]]}}

Different JVM memory per task

  :profiles
  {:dev     {:jvm-opts ["-Xmx512m"]}
   :uberjar {:jvm-opts ["-Xmx2g" "-server"]}}

Extra source dir for dev utilities

  :profiles
  {:dev {:source-paths ["dev"]}}

dev/user.clj — good place for REPL helper functions and startup code.

Plugins

Plugins extend what lein can do.

Where to Put Them

Global — your personal machine only
Good for personal tools you want in every project.

  ;; ~/.lein/profiles.clj  (not in the project repo)
  {:user
    {:plugins [[lein-ancient "0.7.0"]
               [lein-pprint "1.3.2"]]}}

Top-level — for everyone on the project
Committed to git. Every developer gets these when they clone.

  (defproject my-app "0.1.0-SNAPSHOT"
    :plugins [[lein-ring "0.12.6"]
              [lein-ancient "0.7.0"]])

Inside a profile — conditional
Only active when that profile is active.

  :profiles
  {:dev
    {:plugins [[lein-test-refresh "0.25.0"]
               [lein-cljfmt "0.9.2"]]}

   :uberjar
    {:plugins [[lein-shell "0.5.0"]]}}

Most Useful Plugins

Web Development

  ;; Run Ring/Compojure apps with auto-reload
  [lein-ring "0.12.6"]
  lein ring server        ; open browser automatically
  lein ring server-headless
  lein ring uberjar       ; build deployable war

  ;; ring config in project.clj
  :ring
  {;; Required: your main handler function
   :handler my-app.core/app

   ;; Port (default 3000, overridden by $PORT env var)
   :port 3000

   ;; Auto-reload namespaces on file change
   :auto-reload? true

   ;; Which namespaces to watch for reload
   :reload-paths ["src"]

   ;; Run this function before server starts
   :init my-app.core/init

   ;; Run this function when server stops
   :destroy my-app.core/destroy

   ;; Open browser on start (default true with `lein ring server`)
   :open-browser? true

   ;; For WAR packaging: servlet name
   :war {:name "my-app"}}

Testing Ring Handlers

Use ring-mock — no server needed:

  :profiles {:dev {:dependencies [[ring/ring-mock "0.4.0"]]}}

  (ns my-app.core-test
    (:require [clojure.test :refer :all]
              [ring.mock.request :as mock]
              [my-app.core :refer [app]]))

  (deftest test-home
    (let [response (app (mock/request :get "/"))]
      (is (= 200 (:status response)))))

  (deftest test-not-found
    (let [response (app (mock/request :get "/missing"))]
      (is (= 404 (:status response)))))

  (deftest test-post
    (let [response (app (-> (mock/request :post "/users")
                            (mock/json-body {:name "Alice"})))]
      (is (= 201 (:status response)))))

Testing

  ;; Auto-run tests on file save
  [lein-test-refresh "0.25.0"]
  lein test-refresh

  ;; Test coverage report
  [lein-cloverage "1.2.4"]
  lein cloverage
  ;; generates target/coverage/index.html

Code Quality

  ;; Format code (like Prettier)
  [lein-cljfmt "0.9.2"]
  lein cljfmt check       ; show formatting issues
  lein cljfmt fix         ; auto-fix them

  ;; Linter — catches common bugs
  [jonase/eastwood "1.4.3"]
  lein eastwood

  ;; Suggest more idiomatic Clojure
  [lein-kibit "0.1.8"]
  lein kibit

Dependency Management

  ;; Check for outdated dependencies
  [lein-ancient "0.7.0"]
  lein ancient            ; check deps
  lein ancient :all       ; check deps + plugins
  lein ancient upgrade    ; auto-update versions

Finding Plugins

https://clojars.org — search for lein-*
https://github.com/technomancy/leiningen/wiki/Plugins — official plugin list

Aliases

Shortcuts that let you define custom lein commands in project.clj. Instead of typing long commands repeatedly, you define them once and run them with a short name.

Simple Aliases

Single task shortcut

  :aliases
  {"fmt"   ["cljfmt" "fix"]
   "lint"  ["eastwood"]
   "hints" ["kibit"]
   "dev"   ["ring" "server"]}

Example of call
lein fmt

Chaining Tasks with do

Run multiple tasks sequentially — use commas to separate task+args groups:

  :aliases
  {"ci" ["do"
         "clean,"
         "eastwood,"
         "kibit,"
         "test,"
         "uberjar"]}

lein ci ; clean → lint → analyze → test → build

Note: The commas are part of the syntax — they tell do where one task ends and the next begins.

Profile + Task Combos

  :aliases
  {"dev"      ["with-profile" "dev"     "ring" "server"]
   "prod-run" ["with-profile" "prod"    "run"]
   "ci-test"  ["with-profile" "test"    "test"]
   "build"    ["with-profile" "uberjar" "uberjar"]}

lein dev ; start dev server with :dev profile
lein build ; build production jar with :uberjar profil

Why AOT Compilation?

AOT = Ahead-Of-Time compilation

Normally Clojure compiles at runtime (when the JVM starts). AOT means
compiling to .class files before runtime, at build time.

The Problem It Solves
When you run a JAR, the JVM needs a standard Java entry point:
public static void main(String[] args)

Clojure's -main function is not that. It's a Clojure function that gets compiled on the fly when the JVM starts.

Without AOT, the JVM has no idea where to start. It can't find a main
method.

AOT compiles your -main namespace into real .class files with a proper Java main method the JVM can call directly.

What Happens With vs Without AOT ?

Without AOT (lein run):
JVM starts
→ loads Clojure runtime
→ Clojure compiles your namespaces on the fly
→ calls -main
(works fine because lein handles the startup)

With AOT (java -jar my-app.jar):
JVM starts
→ looks for main class in MANIFEST.MF
→ finds compiled .class file ← AOT produced this
→ calls -main
(works because the class file exists)

Concrete Example

(ns my-app.core
    (:gen-class))          ; ← this is also required! tells AOT to generate a
   class

  (defn -main [& args]
    (println "Hello!"))

Without :gen-class in the namespace declaration, even with :aot, the JVM won't find the entry point.

Why Only in the Uberjar Profile?

  :profiles
  {:uberjar {:aot :all}}   ; ← AOT everything for production jar

AOT has downsides in development:

Slower build — compiling everything takes time
Stale classes — if you change code, old .class files can cause confusing bugs
Bigger output — more files in target/

Clojure core.async: A Question & Answer Journey on Channels

ivan.gavlik — Fri, 13 Mar 2026 14:29:49 +0000

Introduction

core.async is Clojure's library for writing concurrent code without dealing with locks, callbacks, or complex threading.

Write asynchronous code that looks synchronous. Your code reads top-to-bottom, even though operations happen concurrently.

Components

Channels: queues that connect producers and consumers. They hold data temporarily and coordinate when to send and receive values
Operations: Non-blocking and blocking put and take operations for sending and receiving data
Go block: Place where you write sequential-looking async code

This post focuses exclusively on Channels. We'll explore Operations (>!, <!, >!!, <!!) and Go blocks in the next posts.

Channels

What exactly is a channel?

A channel is much more than a simple queue—it's a coordination mechanism that manages communication between independent processes

Internal Structure:

Every channel maintains four key components:

Buffer: Optional fixed-size queue holding values in transit. Can be:

nil (unbuffered - rendezvous semantics)
Fixed buffer (bounded queue)
Sliding buffer (drops oldest when full)
Dropping buffer (drops newest when full)

Take Queue: List of consumers waiting to receive values (when buffer is empty)

Put Queue: List of producers waiting to send values (when buffer is full)

Closed Flag + Lock: Thread-safe state management for the channel lifecycle

How data flow in the channel internal structure?

When you put a value on a channel, the implementation checks if any consumers are waiting. If so, the value is handed directly to a waiting consumer. If not, the value goes into the buffer (if there's space), or the producer joins the put queue to wait.

(require '[clojure.core.async :as a :refer [<! >! <!! >!! go go-loop chan close!]])

;; Unbuffered channel - producers and consumers must rendezvous
(def unbuffered-ch (chan))

;; Fixed buffer - can hold up to 10 values before blocking producers
(def buffered-ch (chan 10))

;; Sliding buffer - drops oldest values when full
(def sliding-ch (chan (a/sliding-buffer 5)))

;; Dropping buffer - drops newest values when full
(def dropping-ch (chan (a/dropping-buffer 5)))

;; Demonstration of buffer behavior
(let [ch (chan 2)]  ; Buffer size 2
  (go
    (>! ch 1)  ; Goes into buffer immediately
    (>! ch 2)  ; Goes into buffer immediately
    (println "Put two values")
    (>! ch 3)  ; Blocks here - buffer full, no consumer
    (println "Put third value"))

  (Thread/sleep 100)  ; Let producer run
  (go
    (println "First value:" (<! ch))   ; 1
    (println "Second value:" (<! ch))  ; 2
    (println "Third value:" (<! ch)))) ; 3 - now producer can complete

;; Output:
;; Put two values
;; First value: 1
;; Second value: 2
;; Put third value
;; Third value: 3

What is diff between buffered vs unbuffered channels?

Buffered channel = A mailbox where you can drop letters (items stored until someone picks them up).

Unbuffered channel = Handing something directly to someone (requires both people present at the same time).

Unbuffered channels have no storage capacity. They cannot hold any items at all.
When you do (chan) with no buffer size, you create a channel with a buffer size of 0. This means:

A producer trying to put a value must wait until a consumer is ready to take it
A consumer trying to take a value must wait until a producer is ready to give it
The value passes directly from producer to consumer in a "handshake" (No values are ever stored in the channel itself)

Important Note:
Both buffered and unbuffered channels work with all four operations: >!, <!, >!!, <!!
The difference is in when blocking/parking happens:

Buffered: Only blocks/parks when buffer is full (for puts) or empty (for takes)
Unbuffered: Always blocks/parks until handoff completes

What are use cases for buffered and unbuffered channels?

Buffered Channels Use case

I'm putting this in the queue for you to get to it when you can.

When producers generate data in bursts but consumers process steadily (e.g., user clicking buttons rapidly, but backend processes one request at a time).
When you want to queue up work without blocking the producer (e.g., logging system that accepts messages quickly while writing to disk happens in background)
Email Queue: Marketing system generates 10,000 emails instantly when campaign launches, but email server can only send 100 per minute. Buffer stores the emails while they're sent gradually.
Restaurant Order System: Kitchen receives orders in bursts during lunch rush (10 orders in 2 minutes, then nothing for 5 minutes). Buffer holds the orders so they're not lost, and kitchen processes them steadily.

Unbuffered Channels Use case

When you need confirmation that data was received before continuing (e.g., a worker acknowledging it accepted a task)

Worker Task Assignment: A manager hands work to a team member and waits until they confirm "I've got it" before walking away. You don't want to assume they took the task—you need to see them accept it.
Database Transaction Coordination: Service A completes a database write and must wait for Service B to acknowledge it read the data before A can proceed. Both must be synchronized at that exact moment.
Checkout Process: Customer submits payment, and the system must wait for payment gateway to confirm receipt before showing "Order Placed." Can't just fire-and-forget.
Handshake Protocols: Two systems establishing a connection—client sends "hello," waits for server to respond "hello back" before proceeding. Each step requires mutual acknowledgment.

What happens when a channel closes?

Closing a channel signals "no more values will ever be sent." This is the standard way to communicate completion in core.async pipelines.

Semantics:

Closed channels immediately return nil to all consumers
Attempts to put on a closed channel return false (or throw in blocking operations)
You can still drain values that were buffered before the close
Closing is idempotent—closing an already-closed channel is safe

(def ch (chan 5))

;; Producer sends values then closes
(go
  (>! ch 1)
  (>! ch 2)
  (>! ch 3)
  (close! ch)
  (println "Channel closed")

  ;; Attempting to put on closed channel
  (let [result (>! ch 4)]
    (println "Put after close returned:" result)))  ; false

;; Consumer loops until channel closes
(go-loop []
  (if-some [val (<! ch)]
    (do
      (println "Received:" val)
      (recur))
    (println "Channel closed, exiting")))

;; Output:
;; Received: 1
;; Received: 2
;; Received: 3
;; Channel closed
;; Put after close returned: false
;; Channel closed, exiting

Critical pattern: Use if-some or when-some to distinguish between:

nil because channel closed
nil as an actual value (though sending nil is discouraged)

;; Proper close detection
(go-loop []
  (when-some [val (<! ch)]  ; Continues only if val is non-nil
    (process val)
    (recur))
  ;; Loop exits when channel returns nil (closed)
  (println "Cleanup and shutdown"))

Key Takeaways

Channels are coordination mechanisms, not just queues. They manage the flow of data between independent processes.
Choose your buffer type wisely:
- Unbuffered: When you need rendezvous/handshake semantics
- Fixed buffer: For backpressure and controlled queuing
- Sliding buffer: When newest data matters most (like sensor readings)
- Dropping buffer: When you can afford to lose data under load
Always close channels when production is complete. This is how consumers know to stop waiting.
Use if-some/when-some to properly detect channel closure versus nil values.
Buffered channels decouple producers and consumers in time, while unbuffered channels force synchronization.

What's Next?

Now that you understand how channels work internally and when to use different buffer types, the next post will dive into Operations:

The difference between parking (>!, <!) and blocking (>!!, <!!) operations
When to use each operation type
How go blocks enable efficient concurrent programming
Composing channels with alts!, mult, pub/sub, and pipelines

Clojure Inheritance… Sort Of

Paula Gearon — Thu, 12 Mar 2026 05:49:43 +0000

Disclaimer

I want to start off by saying that I don't expect anyone to read this. However, neither OpenAI nor Anthropic's models get this right on the first try, so I figure that writing about it might get picked up in future training runs.

Inheritance

A pattern that I sometimes want in Clojure is to implement the same function for multiple types (defined by either defrecord or deftype). A simple way to do this is to do the work in an external function, and then have every implementation call it.

For instance, say I want to get a list of feet from several animal types. I can create a protocol for this, with the function get-feet:

(defprotocol Footed
  (get-feet [animal] "Get a sequence of feet"))

Then, I may have a few different groups of animals, each sharing a number of feet. I can create a function for each of these groups:

(defn get-2-feet [] [:left :right])

(defn get-4-feet [] [:front-left :front-right
                     :back-left :back-right])

(defn get-6-feet [] [:front-left :front-right
                     :middle-left :middle-right
                     :back-left :back-right])

Then the different record types will call the function they need:

(defrecord Ape [name]
  Footed
  (get-feet [_] (get-2-feet)))

(defrecord Bird [name]
  Footed
  (get-feet [_] (get-2-feet)))

(defrecord Cat [name]
  Footed
  (get-feet [_] (get-4-feet)))

(defrecord Ant [name]
  Footed
  (get-feet [_] (get-6-feet)))

…and so on.

This works, but it is very unsatisfying. It also gets noisy if the protocol has more than one function.

Instead, it would be nice if we could implement the protocol once, and then inherit this in any type that needs that implementation. Clojure doesn't support inheritance like this, but it has something close.

Protocols

A Protocol in Clojure is a set of functions that an object has agreed to support. The language and compiler have special dispatch support around protocols, making their functions fast and easy to call. While many people know the specifics of protocols, this often comes about through exploration rather than documentation. I won't go into an exhaustive discussion of protocols here, but I will mention a couple of important aspects.

Whenever a protocol is created in Clojure, two things are created: the protocol itself, and a plain-old Java Interface. (ClojureScript also has protocols, but they don't create interfaces). The protocol is just a normal data structure, which we can see at a repl:

user=>  (defprotocol Footed
  (get-feet [animal] "Get a sequence of feet"))
Footed
user=> Footed
{:on user.Footed,
 :on-interface user.Footed,
 :sigs {:get-feet {:tag nil, :name get-feet, :arglists ([animal]), :doc "Get a sequence of feet"}},
 :var #'user/Footed,
 :method-map {:get-feet :get-feet},
 :method-builders {#'user/get-feet #object[user$eval143$fn__144 0x67001148 "user$eval143$fn__144@67001148"]}}

This describes the protocol, and each of the associated functions. This is also the structure that gets modified by some of the various protocol extension macros. You may see how the :method-map refers to functions by their name, rewritten as a keywords.

Of interest here is the reference to the interface user.Footed. I'm using a repl with the default user namespace. Because we are already in this namespace, that Footed interface name is being shadowed by the protocol object. But it is still there, and we can still do things with it.

Common Operations

Protocols are often "extended" onto new datatypes. This is a very flexible operation, and allows new behavior to be associated with any datatype, including those not declared in Clojure (for instance, new behavior could be added to a java.util.String). This applies to Interfaces as well as Classes, which is something we can use here.

First of all, we want a new protocol/interface for each type of behavior that we want:

(defprotocol Feet2)
(defprotocol Feet4)
(defprotocol Feet6)

These protocols don't need functions, as they just serve to "mark" the objects that want to implement the desired behavior.

Next, we can extend the protocol with our functions onto the types described by each of these Interfaces:

(extend-protocol Footed
user.Feet2
(get-feet [_] [:left :right])
user.Feet4
(get-feet [_] [:front-left :front-right :back-left :back-right])
user.Feet6
(get-feet [_] [:front-left :front-right :middle-left :middle-right :back-left :back-right]))

Going back to the Footed protocol, we can see that it now knows about these implementations.

user=> Footed
{:on user.Footed,
 :on-interface user.Footed,
 :sigs {:get-feet {:tag nil, :name get-feet, :arglists ([animal]), :doc "Get a sequence of feet"}},
 :var #'user/Footed,
 :method-map {:get-feet :get-feet},
 :method-builders {#'user/get-feet #object[user$eval143$fn__144 0x67001148 "user$eval143$fn__144@67001148"]},
 :impls {
    user.Feet2 {:get-feet #object[user$eval195$fn__196 0x24fabd0f "user$eval195$fn__196@24fabd0f"]},
    user.Feet4 {:get-feet #object[user$eval199$fn__200 0x250b236d "user$eval199$fn__200@250b236d"]},
    user.Feet6 {:get-feet #object[user$eval203$fn__204 0x61f3fbb8 "user$eval203$fn__204@61f3fbb8"]}}}

Note how the :impls value now maps each of the extended interfaces to the attached functions.

A Comment on Identifiers

You might have noticed that I had to use the fully-qualified name for these interfaces due to the protocol name shadowing them. When a protocol is not in the same namespace, then it can be required, and referenced by its namespace, while the Interface can be imported from that namespace. For instance, a project that I've been working on recently has require/imports of:

(ns my.project
 (:require [quoll.rdf :as rdf])
 (:import [quoll.rdf IRI]))

In this example I am able to reference the protocol via rdf/IRI while the interface is just IRI.

Attaching

Now that the Footed protocol has been extended to each of these interfaces, the protocols associated with those interfaces can be attached to any type that wants that behavior.

Going back to our animals, we can do the same thing again, but this time without the stub functions that redirect to the common functionality:

(defrecord Ape [name] Feet2)
(defrecord Bird [name] Feet2)
(defrecord Cat [name] Feet4)
(defrecord Ant [name] Feet6)

Instances of these types will now pick up the implementations extended to these marker protocols:

(def magilla (Ape. "Magilla"))
(def big-bird (Bird. "Big"))
(def garfield (Cat. "Garfield"))
(def atom-ant (Ant. "Atom"))

user=> (get-feet magilla)
[:left :right]
user=> (get-feet big-bird)
[:left :right]
user=> (get-feet garfield)
[:front-left :front-right :back-left :back-right]
user=> (get-feet atom-ant)
[:front-left :front-right :middle-left :middle-right :back-left :back-right]

Final Declarations

After explaining so much of the mechanism, the code has been scattered widely across this post. Putting the declarations together, we have:

(defprotocol Footed (get-feet [_]))
(defprotocol Feet2)
(defprotocol Feet4)
(defprotocol Feet6)

(extend-protocol Footed
 user.Feet2
 (get-feet [_] [:left :right])
 user.Feet4
 (get-feet [_] [:front-left :front-right :back-left :back-right])
 user.Feet6
 (get-feet [_] [:front-left :front-right :middle-left :middle-right  :back-left :back-right]))

(defrecord Ape [name] Feet2)
(defrecord Bird [name] Feet2)
(defrecord Cat [name] Feet4)
(defrecord Ant [name] Feet6)

Wrap Up

Functional programming in Clojure is not generally served by having multiple types like this, but it does happen. While this is a trivial example, with only a single function on the protocol, the need for this pattern becomes apparent when protocols come with multiple functions.

I've called it inheritance, but that is only an analogy. It's not actually inheritance that we are applying here, but it does behave in a similar way.

Just What IS Clojure, Anyway?

Dimension AI Technologies — Sun, 08 Mar 2026 17:44:46 +0000

Look at this line of code:

processCustomerOrder(customer, orderItems)

Any developer with six months of experience knows roughly what that does. The name is explicit, the structure is familiar, the intent is readable. Now look at this:

(reduce + (map f xs))

The reaction most developers have is immediate and unfavourable. Parentheses everywhere. No obvious structure. It looks less like a programming language and more like a typographer's accident. The old joke writes itself: LISP stands for Lost In Stupid Parentheses.

That joke is, technically, a backronym. John McCarthy named it LISP as a contraction of LISt Processing when he created it in 1958. The sardonic expansion came later, coined by programmers who had opinions about the aesthetic choices involved. Those opinions have not mellowed with time.

And yet Clojure – a modern descendant of Lisp – ranked as one of the highest-paying languages in the Stack Overflow Developer Survey for several consecutive years around 2019. Developers walked away from stable Java and C# positions to build production systems in it. A Brazilian fintech used it to serve tens of millions of customers. Something requires explaining.

The ancestry: Lisp reborn

Clojure only makes sense against the background of Lisp, and Lisp only makes sense as what it actually was: not merely a programming language, but a direct implementation of mathematical ideas about computation.

McCarthy's 1958 creation introduced concepts that took the rest of the industry decades to absorb. Garbage collection, conditional expressions, functional programming, symbolic computation – all present in Lisp before most working developers today were born. Many programmers encounter Lisp's descendants daily without being aware of it.

The defining feature is the S-expression:

(+ 1 2)

Everything is written as a list. This is not merely a syntactic preference. Because code and data share the same underlying structure, a Lisp program can manipulate other programs directly. This property – homoiconicity – is the technical foundation of Lisp macros: code that generates and transforms other code at compile time, with a flexibility that few conventional infix languages match. It is the reason serious Lisp practitioners regard the syntax not as a historical curiosity but as a genuine technical advantage.

Lisp also, however, developed a reputation for producing work that individual experts could write brilliantly and teams could not maintain at all. The tension between expressive power and collective readability never fully resolved. Clojure inherits this tradition knowingly, and is aware of the cost.

What Clojure actually is

The brilliant Rich Hickey created Clojure in 2007. His central design decision was not to build a new runtime from scratch but to attach Lisp to an existing ecosystem.

Layer	Technology
Runtime	JVM
Libraries	Java ecosystem
Language model	Lisp

This host strategy gave Clojure immediate access to decades of mature Java libraries without needing to rebuild any of them. A Clojure developer can call Java code directly. The same logic drove two later variants: ClojureScript, which compiles to JavaScript and found real traction in teams already working with React, and ClojureCLR, which runs on .NET. Rather than fight the unwinnable battle of building its own ecosystem from scratch, Clojure attached itself to three of the largest ones that already existed.

Clojure does not attempt to displace existing ecosystems. It operates inside them.

Central to how Clojure development actually works is the REPL – Read–Eval–Print Loop. Rather than the standard write–compile–run–crash cycle, developers send code fragments to a running system and modify it live. Functions are redefined while the application continues executing. For experienced practitioners this is a material productivity difference: the feedback loop is short, and the distance between an idea and a tested result is small. Experienced Clojure developers report unusually low defect rates, a claim that is plausible given the constraints immutability places on the ways a programme can fail.

The Hickey doctrine: simple versus easy

Hickey's 2011 Strange Loop talk Simple Made Easy is the philosophical engine behind every design choice in Clojure. It draws a distinction that most language design ignores.

Term	Meaning
Easy	Familiar; close to what you already know
Simple	Not intertwined; concerns kept separate

Most languages pursue easy. They aim to resemble natural language, minimise cognitive friction at the point of learning, and reduce the effort required to write the first working programme. This also means that languages favoured by human readers tend to be the hardest for which to write parsers and compilers.

Clojure instead pursues simple. Its goal is to minimise tangled interdependencies in the resulting system, even at the cost of an unfamiliar surface. Writing parsers for Lisps is comparatively straightforward, at the cost of human readability.

Hickey's specific target is what he calls place-oriented programming: the treatment of variables as named locations in memory whose values change over time – mutability, in more formal terms. His argument is that conflating a value with a location generates incidental complexity at scale, particularly in concurrent systems. When you cannot be certain what a variable contains at a given moment, reasoning about a programme becomes difficult in proportion to the programme's size.

The design of Clojure follows directly from this diagnosis. Immutable data, functional composition, minimal syntax, and data structures in place of object hierarchies are all consequences of the same underlying position. The language may not feel easy. The resulting systems are intended to be genuinely simpler to reason about.

The real innovation: data and immutability

Clojure's core model is data-oriented. Rather than building class hierarchies, programmes pass simple structures through functions:

(assoc {:name "Alice" :age 30} :city "London")

This creates a new map. The original is untouched. That is the default behaviour across all of Clojure's data structures – values do not change; new versions are produced instead.

This is made practical by persistent data structures, which use structural sharing. When a new version of a data structure is produced, it shares most of its internal memory with the previous version rather than copying it entirely. The comparison that makes this intuitive for most developers: Git does not delete your previous commits when you push a new one. It stores only the difference, referencing unchanged content from before. Clojure applies the same principle to in-memory data.

The consequence for concurrency results directly from this. Race conditions require mutable shared state. If data cannot be mutated, the precondition for the most common class of concurrency bug does not exist. This was Clojure's most compelling practical argument during the multicore boom of the 2010s, when writing correct concurrent code had become a routine industrial concern rather than a specialist one. Clojure let developers eliminate that entire class of problem.

The functional programming wave – and why easy beat rigorous

Between roughly 2012 and 2020, functional programming moved from academic discussion to genuine industry interest. The drivers were concrete: multicore processors created pressure to write concurrent code correctly; distributed data systems required reasoning about transformation pipelines rather than mutable state; and the sheer complexity of large-scale software made the promise of mathematical rigour appealing.

Clojure was among the most visible representatives of this movement, alongside Haskell, Scala, and F#. Conference talks filled. Engineering blogs ran long series on immutability and monads. For a period it seemed plausible that functional languages might displace the mainstream ones.

What actually happened was different. Mainstream languages absorbed the useful ideas and continued. And the majority of working programmers, it turned out, rarely needed to reason about threading and concurrency at all.

Java gained streams and lambdas in Java 8. JavaScript acquired map, filter, and reduce as first-class patterns, and React popularised unidirectional data flow. C# extended its functional capabilities across successive versions. Rust built immutability and ownership into its type system from the outset. The industry did not convert to functional programming – it extracted what it needed and kept the syntax it already knew.

A developer who can obtain most of functional programming's benefits inside a language they already know will rarely conclude that switching entirely is justified.

The deeper reason functional languages lost the mainstream argument is not technical. It is sociological. Python won because it is, in the most precise sense, the Visual Basic of the current era. That comparison is not an insult – Visual Basic dominated the 1990s because it made programming accessible to people who had no intention of becoming professional developers, and that accessibility produced an enormous, self-reinforcing community. Python did exactly the same thing for data scientists, academics, hobbyists, and beginners, and for precisely the same reason: it is easy to learn, forgiving of error, and immediately rewarding to write. Network effects took care of the rest. Libraries multiplied. Courses proliferated. Employers specified it. The ecosystem became self-sustaining.

Clojure is the antithesis of this process. It is a language for connoisseurs – genuinely, not dismissively. Its internal consistency is elegant, its theoretical foundations are sound, and developers who master it frequently describe it with something approaching aesthetic appreciation. Mathematical beauty, however, has never been a reliable route to mass adoption. Narrow appeal does not generate network effects. And Clojure, by design, operates as something of a lone wolf: it rides atop the JVM rather than integrating natively with the broader currents of modern computing – the web-first tooling, the AI infrastructure, the vast collaborative ecosystems built around Python and JavaScript. At a moment when the decisive advantages in software development come from connectivity, interoperability, and the accumulated weight of shared tooling, a language that demands a clean break from everything a developer already knows is swimming directly against the tide.

Compare this with Kotlin or TypeScript, both of which succeeded in part because they offered a graduated path. A developer new to Kotlin can write essentially Java-style code and improve incrementally. A developer new to TypeScript can begin with plain JavaScript and add types as confidence grows. Both languages have, in effect, a beginner mode. Clojure has no such thing. You either think in Lisp or you do not write Clojure at all.

Where Clojure succeeded

Despite remaining a specialist language, Clojure has real industrial presence.

The most prominent example is Nubank, a Brazilian fintech that reached a valuation of approximately $45 billion at its NYSE listing in December 2021. Nubank runs significant portions of its backend in Clojure, and in 2020 acquired Cognitect – the company that stewards the language. That acquisition was considerably more than a gesture; it was a statement of long-term commitment from an organisation operating at scale.

ClojureScript found parallel influence in the JavaScript ecosystem. The Reagent and re-frame frameworks attracted serious production use, demonstrating that the Clojure model could be applied to front-end development at scale and not merely to backend data pipelines.

The pattern that emerges from successful Clojure deployments is consistent: small, experienced teams working on data-intensive systems where correctness and concurrency matter more than onboarding speed. That is a narrow niche. It was also, not coincidentally, a well-paid one – for a time.

Verdict: the ideas won

Clojure despite its brilliance and initial buzz has not become a mainstream language. By any measure of adoption – survey rankings, job advertisements, GitHub repositories – it remains firmly in specialist territory. Even F#, a functional rival with the full weight of Microsoft's backing - and easier syntax - has not broken through.

But the arguments Clojure made in 2007 has largely been vindicated. Immutability is now a design principle in Rust, Swift, and Kotlin. Functional composition is standard across modern JavaScript and C#. Data-oriented design has become an explicit architectural pattern in game development and systems programming. The industry did not adopt Clojure, but it has been grateful for Hickey's ideas and has in fact hungrily absorbed them.

What did not transfer was the syntax – and behind the syntax lay an economic problem that no philosophical vindication could resolve.

Developers and Heads of Technology might love Clojure for its expressive power and productivity. But a CTO and their C-suite peers evaluating a language does not ask only whether it is technically sound. The questions are: how large is the available talent pool? How long does onboarding take? What happens when a key developer leaves? Does it leave us exposed to key person risk? Clojure's answers to all of these questions are uncomfortable.

There is a further cost that rarely appears in language comparisons. A developer with ten years of experience in Java, C#, or Python carries genuine accumulated capital: hard-won familiarity with idioms, libraries, failure modes, and tooling. Switching to a Lisp-derived language does not extend that knowledge – it resets it. Clojure keeps the JVM underneath but discards almost everything a developer has learned about how to structure solutions idiomatically. The ten-year veteran spends their first six months feeling like a junior again. Recursion replaces loops. Immutable pipelines replace stateful objects. The mental models that took years to build are, at best, partially transferable. They might even fail entirely to transition to functional thinking, after decades in imperative and OOP styles. That cost and those risks are real and largely invisible in adoption discussions, and they fall on precisely the experienced developers an organisation most wants to retain. Knowledge compounds most effectively when it is built upon incrementally. Clojure does not permit that. It demands a clean break, and most organisations and most developers are not willing to pay that price.

The high wages Clojure commanded were not, from a management perspective, a straightforward mark of quality. They were a warning of risk, of "god programmer" lock-in. They reflected something less flattering than productivity: the classic dynamic of the expert who becomes indispensable by writing systems that only they can maintain. At its worst this approaches a form of institutional capture – a codebase so entangled with one person's idiom that replacing them becomes prohibitively expensive, something uncomfortably close to ransomware in its commercial effect.

That position has been further undermined by the rise of agentic coding tools. The practical value of writing in a mainstream language has dramatically increased, because AI coding assistants are trained on the accumulated body of code that exists – and that body is overwhelmingly Python, JavaScript, Java, and C#. The effect is concrete: ask a capable model to produce a complex data transformation in Python and it draws on an enormous foundation of high-quality examples. Ask it to do the same in idiomatic Clojure and the results are less reliable, the suggestions thinner, the tooling shallower. It might have to go through several rounds of trial-and-error. A language's effective learnability in 2026 is no longer a matter only of human cognition; it is also a function of training density. Niche languages are niche in the training data too, and that gap compounds. The expert moat – already questionable on organisational grounds – is being drained from two directions at once.

Clojure's ideas spread widely and rapidly through the languages that absorbed them and left the parentheses behind. Its practitioners, once among the best-paid developers in the industry, now find that the scarcity premium they commanded rested partly on barriers that no longer hold.

So, just what is Clojure, anyway? It is a language that was correct about the most important questions in software design, arrived a decade before the industry was ready to hear the answers, and expressed those answers in a notation the industry was not willing to learn.

The language was right about the future of programming. It might not be part of that future now that it has arrived. But it rightly deserves a place in computing history.

This article is part of an ongoing series examining what programming languages actually are and why they matter.

Language	Argument
C	The irreplaceable foundation
Python	The approachable language
Rust	Safe systems programming
Clojure	Powerful ideas, niche language

Coming next: Zig, Odin, and Nim – three languages that think C's job could be done better, and have very different ideas about how.

Datastar Observations

Howard M. Lewis Ship — Sat, 07 Feb 2026 23:35:22 +0000

I've been very impressed, so far, with Datastar, a tiny JavaScript library for front-end work; I've been switching a personal side-project from using Svelte for it's UI to Datastar, and as amazing as Svelte is, Datastar has impressed me more.

Datastar's essential concept is for the client to shift virtually all logic and all markup rendering back to the server; event handlers can succinctly call server endpoints, which return markup, and the markup is morphed into the running DOM. This makes the server-side is the system of record. Datastar has a nice DSL, based on data-* attributes, allowing you to do nearly anything you need to do in the client, declaratively.

Alternately, the server can start an SSE (server sent event) stream and send down markup to morph into the DOM, or JavaScript to execute, over any period of time. For example, my project has a long running process and it was a snap to create a modal progress dialog and keep it updated as the server-side process looped through its inputs.

The mantra of Datastar is to trust the morph and the browser -- it's surprisingly fast to update even when sending a fair bit of content. It feels wasteful to update a whole page just to change a few small things (say, mark a button as disabled) but it works, and it's fast, and it frees you from a nearly all client-side reactive updates (and all the related edge cases and unforseen consequences).

The server side is not bound to any particular language or framework (they have API implementations for Clojure, Java, Python, Ruby, and many others) ... and you could probably write your own API in an afternoon.

I especially like side-stepping the issue of needing more representations of data; the data lives server-side, all that is ever sent to the client is markup. There's no over-the-wire representation, and no parallel client-side data model. All that's ever exposed as endpoints are intentional ones that do work and deliver markup ... in other words, always use-case based, never schema based.

There's a minimal amount of reactive logic in the client, but the essence of moving the logic to server feels like home; Tapestry (way back in 2005) had some similar ideas, but was far more limited (due to many factors, including JavaScript and browser maturity in that time).

I value simplicity, and Datastar looks to fit my needs without doing so much that is magical or hidden. I consider that a big win!

No, Clojure: your REPL is not new – or best

Dimension AI Technologies — Sat, 20 Dec 2025 11:07:34 +0000

Spend any time around Clojure's devoted community and you'll encounter a cluster of claims:

the Read–Eval–Print Loop ("REPL") is what makes Clojure fundamentally different (REPL – Wikipedia)
REPL-driven development supersedes the Edit–Compile–Run model typical of C-family, .NET and Java
Clojure enables a uniquely live, exploratory way of building systems
other languages "don't really have a REPL"

These claims sound radical, historically grounded and quietly superior, but they are – alas – more rhetoric than fact.

This article challenges established wisdom about Clojure in three areas:

the REPL long predates Clojure
Clojure neither invented nor uniquely exemplifies it
several alternative REPL models outperform Clojure's on important engineering criteria

To be clear, Clojure is a powerful language with dedicated supporters; so what follows is not an attack on Clojure, but a suggestion that its mythology needs a tweak.

The REPL long predates Clojure

Lisp had already established the model by 1958

The Read–Eval–Print Loop originates in Lisp systems developed at MIT in the late 1950s (History of Lisp – Wikipedia). From the outset, Lisp environments supported:

interactive evaluation
incremental definition of functions
inspection and modification of live runtime state
persistent sessions

The terminology itself has a long and well-documented history. The expression "read–eval–print cycle" is used by L. Peter Deutsch and Edmund Berkeley in a 1964 implementation of Lisp on the PDP-1 (Deutsch & Berkeley, 1964). Just one month later, Project MAC published a report by Joseph Weizenbaum — later known as the creator of ELIZA, the world's first chatbot — describing a REPL-based language, OPL-1, implemented in his Fortran-SLIP language on the Compatible Time Sharing System (CTSS) (Weizenbaum, 1964; CTSS – Wikipedia).

By 1974, the Maclisp Reference Manual by David A. Moon explicitly refers to a "read-eval-print loop" (page 89), even though the acronym "REPL" is not yet used (Moon, 1974).

From at least the early 1980s onward, the abbreviations REP loop and REPL are attested in the context of Scheme, where the term became standard (Scheme REPL terminology history).

Clojure deliberately situates itself within this lineage and explicitly inherits from it.

Once that inheritance is acknowledged, the oft-claimed notion that the REPL distinguishes Clojure needs correction. Any feature drawn wholesale from a sixty-year-old tradition cannot serve as a defining innovation.

ML: a typed REPL from the early 1970s

Alongside Lisp, the original ML language — developed in the early 1970s as part of the Edinburgh LCF project (LCF – Wikipedia) — was explicitly designed for interactive use.

ML's REPL supported incremental definition, immediate evaluation and full static type inference at the prompt. This was not an afterthought. ML was a metalanguage, intended to be explored live while retaining formal guarantees.

This matters because it shows that REPL-driven development under strong static typing is not a modern compromise or a reaction against Lisp. It is a parallel tradition, older than Clojure by decades.

Smalltalk pushed live systems further in the 1970s

Smalltalk systems went beyond REPL interaction and embraced image-based development (Smalltalk – Wikipedia), where the entire system existed as a continuously mutable artefact. Programs were edited while running; the notion of a clean restart receded into the background.

This approach predates Clojure by decades and represents a more radical commitment to liveness than Clojure's own model.

However one judges Smalltalk today, its existence alone undermines the idea that live, interactive programming is a modern breakthrough.

Home computers normalised persistent REPLs

The most consequential historical counterexample is neither Lisp nor Smalltalk. It is home computing.

From the late 1970s through the mid-1980s, the overwhelming majority of home computers booted directly into a persistent BASIC environment (BASIC – Wikipedia). Immediate mode was the primary interface. Variables survived RUN. Programs routinely relied on pre-initialised state in order to function within severe memory constraints.

This behaviour was universal and far from exceptional.

Home-computer BASIC: persistent REPL as the default interface

Machine	Year	BASIC variant	Persistent variables	Immediate mode
TRS-80 Model I	1977	Microsoft BASIC	Yes	Yes
Commodore PET	1977	Microsoft BASIC	Yes	Yes
Apple II	1977	Applesoft BASIC	Yes	Yes
Atari 400/800	1979	Atari BASIC	Yes	Yes
ZX-80	1980	Sinclair BASIC	Yes	Yes
VIC-20	1981	Commodore BASIC 2.0	Yes	Yes
ZX-81	1981	Sinclair BASIC	Yes	Yes
BBC Model A	1981	BBC BASIC	Yes	Yes
BBC Model B	1981	BBC BASIC	Yes	Yes
ZX Spectrum	1982	Sinclair BASIC	Yes	Yes
Commodore 64	1982	Commodore BASIC 2.0	Yes	Yes
Dragon 32/64	1982–83	Microsoft BASIC	Yes	Yes
Oric-1	1983	Oric Extended BASIC	Yes	Yes
Amstrad CPC	1984	Locomotive BASIC	Yes	Yes

Tens of millions of machines shipped with precisely this interaction model.

Rather than being an esoteric Lisp technique rediscovered decades later, the "tight feedback loop" was simply how personal computing worked for an entire generation. Many senior industry figures learned their craft in that world.

It is also worth noting that the BASIC world itself once abandoned the interactive model it had popularised. Early BASIC systems treated the programming environment as a live, persistent session. With the move to Visual Basic and later VB.NET (Visual Basic – Wikipedia; VB.NET – Wikipedia), that model gave way to an IDE-centred, project-based workflow, where code was edited, built and executed as a discrete artefact.

This shifted BASIC from language-as-environment to language-as-artifact.

Interactivity did not vanish entirely, but it moved from the language to the tooling, and the REPL ceased to be the organising centre.

Erlang demonstrated live code in production

To argue that Clojure uniquely enables live mutation of running systems means overlooking Erlang, the telecoms language created by Ericsson (Erlang – Wikipedia).

From the late 1980s onward, Erlang supported hot code swapping in safety-critical telephony infrastructure. Far from exploratory hacking, this was production engineering under strict uptime requirements.

Live systems were already operational long before Clojure appeared.

What Clojure actually contributes

Clojure's achievement lies elsewhere.

It brings together:

the Lisp REPL tradition
the JVM ecosystem
persistent data structures (Persistent data structure – Wikipedia)
modern concurrency primitives

This synthesis is real and valuable, and the result of thoughtful engineering.

Interactive programming and the REPL itself, however, sit firmly in the inherited category.

The real trade-off: semantic mutability

The distinctive characteristic of Clojure's REPL is not persistence per se, but the level at which persistence operates.

Early BASIC systems preserved data. Numbers, arrays and flags survived across runs. Control flow remained linear, and program meaning remained fixed.

Clojure extends persistence to meaning. Functions may be redefined live. Dispatch rules can be altered. Existing call sites can acquire new behaviour without any obvious signpost.

This shift increases expressive power, but the engineering bill arrives as reduced reconstructability and predictability.

Clojure: silent semantic drift

;; Session start: define calculate
user=> (defn calculate [x] (* x 2))
#'user/calculate

user=> (calculate 5)
10

;; Later, perhaps in another file or by another developer:
user=> (defn calculate [x] (+ x 100))   ; silently replaces original
#'user/calculate

user=> (calculate 5)
105
;; No warning. No error. Source file unchanged.

For a single developer, this is simply a useful tool. In a team, it becomes a coordination hazard: runtime truth can drift away from the text everyone believes they are running.

On Rich Hickey's position

In talks such as Simple Made Easy (InfoQ video) and various discussions of REPL-driven development, Rich Hickey has argued that interactive development should be central, while edit–compile–run should be viewed as inefficient.

The intuition behind this argument is understandable. Iteration speed matters.

The framing, however, tends to obscure two facts:

interactive development long predates Clojure
many systems combine interactivity with compilation discipline

Growing systems live accelerates exploration, but it also erodes the ability to reconstruct behaviour from source alone. That trade-off deserves to be stated explicitly.

Hickey did not claim the REPL was new. The Clojure community, however, often treats it as a unique truth.

A structural comparison

A clearer perspective emerges from comparing REPL models across history.

Legend: ✅ Yes, ❌ No, 🟡 Limited

Property	1958–60: Lisp REPL (image-based)	1964: Dartmouth BASIC	1977–85: Home BASIC	1973–: ML / OCaml REPL	2005–: F# REPL	2007–: Clojure REPL
Interactive evaluation	✅	✅	✅	✅	✅	✅
Immediate mode	✅	✅	✅	✅	✅	✅
Persistent session	✅	❌	✅	✅	✅	✅
Variables persist across runs	✅	❌	✅	✅	✅	✅
First-class functions	✅	❌	❌	✅	✅	✅
Live function redefinition	✅	❌	❌*	🟡	🟡	✅
Behavioural semantics mutable live	✅	❌	❌	❌	🟡	✅
Static type checking	❌	❌	❌	✅	✅	❌
Type system constrains REPL	❌	❌	❌	✅	✅	❌
Silent semantic mutation possible	✅	❌	❌	✅	✅	✅
Reconstructable from source alone	❌	✅	✅	✅	✅	❌
Designed for long-lived systems	✅	❌	❌	✅	✅	✅

BBC BASIC excepted; most home BASICs lacked named functions and relied on line-numbered subroutines.

A counterexample: the ML lineage (OCaml and F#)

F# is not an outlier. It belongs to a lineage – ML and OCaml (OCaml – Wikipedia) – that has treated interactive, typed REPL-driven development as normal practice for over forty years.

F#'s REPL chooses constraint over maximal dynamism, but the mechanism deserves to be described accurately.

F# allows shadowing with a new binding. When type signatures match, however, F# offers no protection against semantic drift – the same 'silent mutation' problem exists as in Clojure:

// F#: type system provides no protection when signatures match
> let calculate x = x * 2;;
val calculate: x: int -> int

> calculate 5;;
val it: int = 10

> let calculate x = x + 100;;   // same signature, different semantics
val calculate: x: int -> int

> calculate 5;;
val it: int = 105
// Same silent semantic drift as Clojure

The difference is that F#'s type system provides partial protection: it prevents one class of errors (type mismatches at call sites) but not semantic changes within the same type. When a function is redefined with a different type signature, the type system catches inconsistent usage at the point of application, forcing the programmer to address the incompatibility explicitly.

For teams that value refactoring, long-term maintenance and source-level truth, this partial discipline often proves advantageous – though it does not eliminate the reconstructability problem entirely.

"But Clojure's REPL is integrated"

A predictable rebuttal points to tooling: CIDER (https://cider.mx), nREPL (https://nrepl.org) and editor integration.

Better tools improve the experience. They do not alter the underlying model, which remains rooted in a design first implemented in the 1950s.

Why the mythology persists

The persistence of the REPL myth is easy to explain:

Lisp culture has always emphasised interactivity
computing history before the web is poorly remembered
expressive power is often confused with novelty
difficulty is frequently mistaken for depth

None of this indicates bad faith, but it does reward clearer framing.

This transition took place more than a generation ago. As a consequence, the interactive environments that once defined everyday programming gradually slipped from the memory of both enthusiasts and professionals. Later rediscoveries of REPL-driven workflows were then easily mistaken for innovations rather than revivals.

Conclusion

The REPL is an immensely valuable tool. Its lineage stretches back more than six decades. Clojure's indisputable power rests heavily on it, but that power arrives through inheritance rather than invention.

Other languages explore the same design space differently, sometimes with stronger engineering constraints.

It is also worth noting a structural echo. REPL-driven workflows treat programming as a dialogue rather than a batch process, and today's agent-driven coding tools adopt a similar stance. They extend the conversational model from interaction with a running program to interaction with an entire codebase. It would be a stretch to claim a direct causal link, but the resemblance is clear: both approaches reject the assumption that code must be "finished" before it can be tested against reality.

Clojure's REPL offers power and has made a great deal of noise. It has reinvigorated an old paradigm and delighted its community. Power is not, however, novelty; and enthusiasm must not rewrite history.

Acknowledgments

Thanks to Frank Adrian for pointing out that the original F# example compared type-system differences rather than REPL-model differences. The corrected example now shows how F#, like Clojure, permits silent semantic drift when function signatures remain unchanged; the F# type system provides only partial protection against this class of error.

References

Read–Eval–Print Loop (REPL) – Wikipedia
https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop
History of Lisp – Wikipedia
https://en.wikipedia.org/wiki/History_of_Lisp
L. Peter Deutsch & Edmund Berkeley, LISP on the PDP-1 (1964)
https://softwarepreservation.computerhistory.org/projects/LISP/book/III_LispBook_Apr66.pdf
Joseph Weizenbaum, OPL-1 on CTSS (1964)
https://dspace.mit.edu/handle/1721.1/149332
Compatible Time-Sharing System (CTSS) – Wikipedia
https://en.wikipedia.org/wiki/Compatible_Time-Sharing_System
David A. Moon, Maclisp Reference Manual (1974)
https://www.softwarepreservation.org/projects/LISP/MIT/Moon-MACLISP_Reference_Manual-Apr_08_1974.pdf
Scheme REPL terminology history
https://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop
Edinburgh LCF – Wikipedia
https://en.wikipedia.org/wiki/Edinburgh_LCF
Smalltalk – Wikipedia
https://en.wikipedia.org/wiki/Smalltalk
BASIC – Wikipedia
https://en.wikipedia.org/wiki/BASIC
Visual Basic (classic) – Wikipedia
https://en.wikipedia.org/wiki/Visual_Basic_(classic)
VB.NET – Wikipedia
https://en.wikipedia.org/wiki/Visual_Basic_.NET
Erlang (programming language) – Wikipedia
https://en.wikipedia.org/wiki/Erlang_(programming_language)
Persistent data structure – Wikipedia
https://en.wikipedia.org/wiki/Persistent_data_structure
Rich Hickey, Simple Made Easy (InfoQ video)
https://www.infoq.com/presentations/Simple-Made-Easy/
OCaml – Wikipedia
https://en.wikipedia.org/wiki/OCaml
CIDER
https://cider.mx
nREPL
https://nrepl.org

What it was like to give a talk at Clojure South 2025

Marcio Frayze — Wed, 03 Dec 2025 14:45:59 +0000

What is Clojure South?

According to the official website:

"Organized by Nubank, Clojure South is part of the official Clojure community schedule, connecting developers, enthusiasts, and companies to share real experiences, discuss trends, and strengthen the global network of the language." - Translated from Brazilian Portuguese by me.

Motivation

In a conversation with a Brazilian woman I met at Lambda Days 2025 (I talked about what it was like to attend this event in this article), I asked if she would attend the conference (she works at Nubank) and found out she would be an instructor for the Clojure workshop. During this conversation, she suggested that I should submit a talk proposal. I mentioned an idea I had in mind but was feeling a bit insecure about sending it. She encouraged me to try, and I decided to take a chance!

Although I already have some talks on my resume, I felt that maybe I should be more cautious in this case, and submit a proposal for a lightning talk (a 10-minute talk with no time for questions).

A few weeks later, to my surprise, the proposal was accepted!

Theme

I had two possible topics in mind. One about teaching Clojure and Functional Programming to beginners (because of my course Clojure: Introdução à Programação Funcional; an Introduction to Functional Programming through Clojure, for Brazilians). And another about a project I built at the company where I work, using Clojure in the backend and the programming language Elm for the front-end.

I chose the second one. It was already a project I wanted to talk about publicly, and this seemed like a great opportunity!

Another factor is that the project is related to a very well-known App in Brazil, the Digital Driver's License — an App developed by SERPRO and available for Android and iOS. I imagined this could increase the chances of the talk being accepted.

The full description I submitted was:

During the development of the Carteira Digital de Trânsito (Digital Driver's License), I realized how challenging it was to support an App with millions of users integrated with many systems. I dreamed of creating a simple, friendly internal interface for queries that would make support easier. That’s how Apoio CDT was born, a web system that automated processes and enabled fast and secure queries. With a Clojure backend and an Elm front-end, we developed an MVP in three weeks. The result was a simple, efficient, and easy-to-maintain web architecture over the years.

As far as I know, this was the company’s first project using Clojure and also the first using Elm. And it was the first time I had the opportunity to talk about this system to people outside the company where I work!

Other Talks and Workshops

The event lasted two days, and the first day featured the two workshops:

Clojure Workshop

An introductory Clojure course, in English, taught by Christoph Neumann, Clojure Developer Advocate at Nubank.

Although I already have experience with Clojure, it was great to reinforce the main concepts of the language and I even learned some fundamentals I didn’t know yet!

Datomic Workshop

The afternoon of the first day was dedicated to the workshop of the Datomic database. It was taught in Brazilian Portuguese by Carolina Silva (the same one I mentioned at the beginning of this article) and Hanna Figueiredo, both Software Engineers at Nubank.

I had already watched several talks about Datomic and always found it an intriguing and interesting database. I believe it would make a lot of sense to use it in several projects I have worked on or currently work on.

The workshop covered many theoretical concepts of Datomic, but it was also very hands-on.

You can check out the hands-on portion of the workshop in this GitHub repository!

I confess it was a lot of information in a short time. I will definitely need to revisit the repository and practice a lot more to internalize the core concepts of this database. But it was totally worth it!

If before I already thought studying this database was worthwhile, now I’m certain of it!

Conversations and Feedback

Right when I arrived at the event, I had the chance to talk to some people I only knew online, such as Arthur Fücher. Besides being a Senior Software Engineer at Nubank, Arthur is very active in the Brazilian Clojure community!

And even though I am quite shy, I was able to meet many great people from Brazil and other countries.

In particular, I was welcomed very warmly by Christoph Neumann. I was standing quietly in a corner during the happy hour, after the second day of the event, eating and thinking about heading home, when he approached me and started a conversation. We talked a bit, and I began asking a few questions about Datomic. During the conversation, I mentioned that Datomic might be a good fit for the company where I work. When I said what the company does, he became very interested! And soon offered to introduce me to Joe Lane, Principal Engineer Building Datomic at Nubank!

I talked to Joe and, again, was very kindly received! He seemed genuinely excited when I mentioned where I worked and the types of projects SERPRO develops, and he offered to answer any questions about Datomic — even mentioning that SERPRO could be a great Datomic case study.

During the event, I also had the opportunity to meet people who took my Clojure course! Among them, I met Bruno Guimarães, currently a Senior Software Engineer at Nubank and the host of the conference.

Meeting students of my online course in person is always a very special experience! The numbers, the stats, the comments — they gain a face, a voice, life. It's truly rewarding!

On the second day, after my talk, many people came to talk and learn more about how I introduced Clojure into a federal government system in Brazil. Some had specific questions about my motivation for using Elm on the front-end (instead of opting for ClojureScript), plus several other interesting conversations.

The feedback was very positive, and all the conversations were friendly, fun, and respectful.

Food (and More Conversations)

The event had a welcome coffee in the morning and coffee breaks throughout the day. The quality was excellent and everything was quite formal (maybe a bit too formal? lol).

For lunch, there were several options (not included in the ticket price) within the same building complex where Nubank Sparks is located. This made things much easier, especially on the workshop day, since I had my laptop with me.

You could eat wherever you wanted. But I liked the nearby options, and it became yet another opportunity to talk to more people from the event. Again, even being shy and sitting somewhere more secluded, several people soon came to sit with me and chat. At that moment, I met a Ukrainian attendee who showed us the Diia App, where she can have digital versions of several documents such as her Driver’s License, Passport, and more — with access to over 130 government services (you can learn more about this App on its Wikipedia page)!

Was It Worth It?

Definitely, yes!

The event happened on two weekdays (a Monday and Tuesday). This may make it difficult for some people to attend — for example, a colleague of mine couldn’t go because his company didn’t allow him to take those days off. But for those who can attend, it’s far less tiring than having an event like this over the weekend after a long workweek.

I had purchased the early-bird tickets before my talk was accepted, but later the event organizers refunded me — I received free tickets for both days as a speaker. They also offered help with transportation and lodging, which I declined since the event was close to where I live.

The experience of speaking at an event of this magnitude, even if only for 10 minutes, was incredible! It’s a feeling of great gratitude to the people who organized the conference and who trusted in my potential!

Did you like this article? Don't forget to leave a reaction! They serve as a big incentive for me to write others.

You can also discover more articles, podcasts and videos at: https://segunda.tech/tags/english.

And if you want, follow me on twitter, blue sky and Linkedin.

Como foi palestrar na Clojure South 2025

Marcio Frayze — Sun, 23 Nov 2025 21:40:28 +0000

O que é a Clojure South?

Segundo site oficial:

"Organizada pelo Nubank, a Clojure South faz parte da programação oficial da comunidade de Clojure, conectando pessoas desenvolvedoras, entusiastas e empresas para compartilhar experiências reais, discutir tendências e fortalecer a rede global da linguagem."

Motivação

Em uma conversa com uma brasileira que conheci na Lambda Days 2025 (falei sobre como foi participar deste evento neste artigo), perguntei se ela iria assistir às palestras (ela trabalha para a Nubank) e descobri que ela iria ser instrutora do workshop de Clojure! Nesta conversa ela sugeriu que eu deveria enviar uma proposta de palestra. Comentei uma ideia que eu tinha para submeter, mas que estava meio inseguro de enviar. Ela me encorajou a tentar e eu resolvi arriscar!

Embora tenha no meu currículo algumas palestras e participações em podcasts, sentia que talvez fosse mais interessante, neste caso, submeter uma proposta no formato lighting talk (palestra de apenas 10 minutos e sem tempo para perguntas).

E algum tempo depois, para minha surpresa, a proposta foi aceita!

Tema

Havia pensado em enviar propostas sobre dois possíveis temas. Um sobre o ensino de Clojure e Programação Funcional para iniciantes (por conta do meu curso Clojure: Introdução à Programação Funcional). E outro sobre um projeto que fiz na empresa onde trabalho, que utiliza Clojure no backend e a linguagem de programação Elm para o front-end.

Optei pela segunda opção. Já era um projeto que eu queria falar sobre publicamente e esta parecia ser uma boa oportunidade!

Outro fator é que o projeto em questão está relacionado com um App bastante famoso no Brasil, a Carteira Digital de Trânsito — App desenvolvido pelo SERPRO e disponível para Android e iOS. Imaginava que isso poderia aumentar as chances de a palestra ser aceita.

A descrição completa que enviei foi:

Durante o desenvolvimento da Carteira Digital de Trânsito, percebi como era desafiador dar suporte a um App com milhões de usuários integrado a diversos sistemas. Sonhei em criar uma interface interna simples e amigável para consultas que facilitassem o atendimento. Assim surgiu o Apoio CDT, um sistema web que automatizou processos e permitiu consultas rápidas e seguras. Com backend em Clojure e front-end em Elm, desenvolvemos um MVP em três semanas. O resultado foi uma arquitetura web simples, eficiente e fácil de manter ao longo dos anos.

Até onde sei, este foi o primeiro projeto da empresa que utilizada Clojure e também o primeiro a utilizar Elm. E esta foi a primeira vez que tive oportunidade de falar sobres este sistema para pessoas de fora da empresa onde trabalho!

Demais palestras e workshops

O evento durou dois dias, sendo que no primeiro ocorreram os 2 workshops:

Workshop de Clojure

Um curso de introdução ao Clojure, em inglês, ministrado pelo Christoph Neumann, Developer Advocate de Clojure no Nubank.

Embora eu já tenha experiência com Clojure (e inclusive seja instrutor do curso Clojure: Introdução à Programação Funcional), foi muito legal reforçar os principais conceitos desta linguagem e também aprendi alguns fundamentos que ainda não conhecia!

Workshop de Datomic

O período da tarde do primeiro dia foi destinado ao workshow do banco de dados Datomic. Este foi ministrado em português pela Carolina Silva (a mesma que citei no começo deste artigo) e Hanna Figueiredo, ambas Software Engineering no Nubank.

Eu já havia assistido várias palestras sobre o Datomic e sempre achei um banco de dados muito intrigante e interessante. Acredito que faria muito sentido utilizá-lo em vários dos projetos que atuo ou já atuei no passado.

O workshop mostrou vários conceitos teóricos do Datomic, mas também foi muito prático.

Você pode conferir a parte prática do workshop neste repositório do GitHub!

Confesso que foi muitas informações em pouco tempo. Definitivamente, vou precisar voltar ao repositório e praticar bastante ainda para internalizar os principais conceitos deste banco de dados. Mas valeu muito a pena!

Se antes eu achava que valeria a pena estudar este banco, agora tenho certeza!

Conversas e feedbacks

Logo ao chegar no evento tive a oportunidade de conversar com algumas pessoas que só conhecia virtualmente, como o Arthur Fücher. Além de ser Senior Software Engineer no Nubank, Arthur é uma figura muito presente na comunidade Clojure do Brasil!

E mesmo sendo uma pessoa bastante tímida, foi possível conhecer muitas pessoas bacanas do Brasil e de outros países.

Em especial, fui muito bem recebido pelo Christoph Neumann. Eu estava parado em um canto no happy hour, após o segundo dia de evento, comendo e pensando em já ir pra casa, quando ele se aproximou e puxou conversa. Conversamos um pouco e comecei a fazer algumas perguntas sobre Datomic. Ao longo da conversa, citei que talvez fosse um banco de dados interessante para empresa onde trabalho. Quando falei onde trabalhava e o que a empresa fazia, ele se mostrou bastante interessado! E logo se ofereceu para me apresentar o Joe Lane, Principal Engineer Building Datomic na Nubank!

Conversei com o Joe e, mais uma vez, fui super bem recebido! Ele mostrou bastante entusiasmo quando comentei onde trabalhava e os tipos de projetos que o SERPRO desenvolve, e ficou à disposição para tirar dúvidas sobre Datomic, inclusive comentando que o SERPRO poderia ser um ótimo case para o Datomic.

Ao longo do evento também tive a oportunidade de conhecer algumas pessoas que fizeram meu curso de Clojure! Entre essas pessoas, conheci o Bruno Guimarães, que atualmente é Senior Software Engineer no Nubank e foi host da conferência.

Conhecer pessoalmente pessoas que fizeram meu curso online é sempre uma experiência muito legal! Os números, as estatísticas, os comentários, ganham um cara, uma voz, vida. É sempre muito gratificante!

No segundo dia, após a minha apresentação, muitas pessoas vieram conversar e querer saber mais sobre como consegui introduzir Clojure em um sistema do governo federal brasileiro. Tiveram algumas dúvidas mais pontuais, sobre minha motivação para usar Elm no front-end (e não optar por utilizar Clojure em sua versão ClojureScript), entre várias outras conversas interessantes.

O feedback foi bastante positivo e todas as conversas foram muito bacanas, bem humoradas e respeitosas.

Comidas (e mais conversas)

O evento contava com welcome coffee no início do dia e coffee breaks ao longo do dia. A qualidade era muito boa e tudo muito formal (talvez formal até um pouco demais? rs).

Já para almoçar, existiam várias opções (não inclusas no valor do ingresso) de restaurantes dentro do mesmo complexo de prédios onde encontra-se a Nubank Sparks. Isso facilitava bastante, já que não precisava sair do local, especialmente no primeiro dia, de workshops, já que estava com meu notebook.

Você pode almoçar onde quiser. Mas gostei das opções que estavam disponíveis ali perto e foi mais uma oportunidade de conversar com mais pessoas do evento. Novamente, mesmo sendo bastante tímido e sentando em um lugar mais afastado, logo vieram várias pessoas sentar junto comigo e puxar conversa. Neste momento conheci uma Ucraniana que mostrou pra gente o App Diia, onde ela pode ter versões digitais de vários de seus documentos, como Carteira de Motorista, Passaporte, entre outros e ter acesso a mais de 130 serviços do governo Ucraniano (você pode saber mais sobre este App nesta página do Wikipedia)!

Valeu a pena?

Definitivamente, sim!

O evento ocorreu em dois dias da semana (uma segunda e terça-feira). Isso talvez atrapalhe a participação de algumas pessoas — um colega meu não conseguiu participar pois a empresa não liberou este dias para ele, por exemplo. Mas para aquelas pessoas que conseguem participar, fica muito menos cansativo do que ter um evento como este no final de semana, depois de uma longa semana de trabalho.

Eu havia comprado os ingressos na pré-venda, antes de ter minha palestra aprovada, mas depois tive o valor estornado pela coordenação do evento - ganhei ingressos para os dois dias por ser palestrante. Também me ofereceram ajuda para transporte e estadia, a qual eu recusei, já que o evento seria próximo da minha residência.

A experiência de palestrar em um evento desta magnitude, mesmo que por apenas 10 minutos, foi incrível! É uma sensação de muita gratidão às pessoas que ajudaram a organizar a conferência e que confiaram no meu potencial!

Native Apps with ClojureScript, React and Static Hermes

Roman Liutikov — Mon, 17 Nov 2025 16:00:00 +0000

What you see in the demo below is ClojureScript UIx app driving native window with ImGui UI via custom React reconciler. Both hot-reloading and REPL-driven development are supported, as you'd expect it from a typical ClojureScript project.

The JavaScript side of the app runs in Hermes engine, which exposes ImGui to JS env. However, a release build of this exact app is a fully native 8MB executable. You can try it yourself on macOS or Linux.

While Hermes engine is a JavaScript VM, it is also an AOT compiler for JavaScript that emits either Hermes byte code or C.

Compiling this sample JavaScript program with Static Hermes: shermes -emit-c index.js

print(1 + globalThis.value);

outputs the following C program or 50KB executable, when compiled straight into a binary shermes -Os index.js

locals.t0 = _sh_ljs_get_global_object(shr);
frame[3] = _sh_ljs_try_get_by_id_rjs(shr,&locals.t0, get_symbols(shUnit)[1] /*print*/, get_read_prop_cache(shUnit) + 0);
locals.t0 = _sh_ljs_try_get_by_id_rjs(shr,&locals.t0, get_symbols(shUnit)[2] /*globalThis*/, get_read_prop_cache(shUnit) + 1);
locals.t0 = _sh_ljs_get_by_id_rjs(shr,&locals.t0,get_symbols(shUnit)[3] /*value*/, get_read_prop_cache(shUnit) + 2);
np0 = _sh_ljs_double(1);
frame[1] = _sh_ljs_add_rjs(shr, &np0, &locals.t0); // 1 + globalThis.value
np0 = _sh_ljs_undefined();
frame[4] = _sh_ljs_undefined();
frame[2] = _sh_ljs_undefined();
locals.t0 = _sh_ljs_call(shr, frame, 1);
_sh_leave(shr, &locals.head, frame);
return np0;

The above demo is 8MB executable on macOS, where 3MB is Hermes runtime, 1.8MB is React the JavaScript library compiled to C and the rest 3.2MB goes to native libraries ImGui and libwebsockets, and ClojureScript code compiled to C.

Here's a rough diagram of how things are bundled in the executable.

You may noticed there's untyped and typed JavaScript. When AOT compiling typed JavaScript, which can be a subset of either TypeScript or Flow, Hermes emits a more optimal C making it suitable for performance sensitive code, such as bindings to native libraries runnning in a hot loop.

As an example, compiling the following typed program with -typed flag: shermes -typed -emit-c index.js

function add(a: number): number {
  return a + globalThis.value;
}
print(add(1));

emits C that:

doesn’t create an add function/closure, instead the arithmetic is emitted inline
adds type assertion for unkown value globalThis.value
includes fewer symbols & caches

You can check both typed and untyped C here, here's also a diff to make it more obvious.

As I said earlier, the app runs raw JavaScript in dev to provide fast feedback loop and support interactive development. This is possible because Hermes has multiple tiers of code optimization:

During developent JavaScript VM loads the code and emits byte code (JIT) at runtime
You can also compile JavaScript to bytecode (.hbc file) ahead of time. This use case is quite popular in React Native, where application code is compiled into Hermes bytecode at build time to improve startup time of mobile apps, especially on Android.
Finally, with Static Hermes you can compile JavaScript to native object file. This way you get statically linked machine code, skipping parsing and JIT.

Now the best part about this setup is actually React itself. I didn't have to change anything in UIx to make it work with original imgui-react-runtime demo. The real power and a curse of React is that it is a platform independent abstraction. It's up to the host platform to provide specific realization of the contract. If you are Clojure developer, this might sound familiar to you.

The abstraction in question is React's reconciler. By implementing its interface you can create custom render targets, such as React Native, PixiJS React, react-three-fiber, you can even create Terminal UIs and PDFs with it. Heck, if you take a step back and think about the reconciler as a generic abstraction for turning declarative description of something into a set of imperative operations, you can even run hardware with it.

Ok, so how fast is AOT compiled JavaScript with Static Hermes? Here's a quick benchmark:

(simple-benchmark []
    (->> (range)
         (map inc)
         (filter odd?)
         (map #(zipmap (repeatedly % Math/random) (repeatedly % Math/random)))
         (take 1e2)
         (reduce #(apply + %1 (mapcat identity %2)) 0))
    1e2)

Optimized executable runs for ~6450 ms. Same code executed as JavaScript in Node and Bun runs for ~1100 ms. That's 6x slower, ouch. On the bright side, the executable is just a few MBs, while embedding JS VM will get you at least up to 60MB in the case of Bun. If you ask me, I'll always prefer 6x faster app, doesn't matter how big it is.

However, the case with React is quite specific. React being a declarative abstraction on top of imperative APIs almost always means that hot code paths are executed in underlying layers, whether it's browser's DOM, mobile views, WebGL or ImGui. And often times you have an option to use that lower level, more performant API directly, when needed.

Hermes was originally developed for React Native and mobile apps, with a focus on improving startup performance. Even generated native code can't compete with JITs in modern JavaScript engines.

Bonus point. Similarly to how shadow-cljs displays compiler warnings and errors in a browser, the demo ImGui app also captures and displays warnings and errors, as well as includes an error boundary component that catches runtime exceptions thrown during render phase.

Checkout the code of this project at roman01la/cljs-static-hermes, which is based off the work done by a member of Hermes team, at tmikov/imgui-react-runtime. If you are interested in driving native window from runtimes like Node or Bun, checkout this project showcasing use of Bun's FFI to interface with GLFW and OpenGL: roman01la/hra.

Advanced Beginner’s guide to ClojureScript

Roman Liutikov — Fri, 07 Nov 2025 20:00:00 +0000

So how does your tiny ClojureScript program transform into runnable JavaScript?

(ns app.core)

(println "Howdy!")

First of all, you need a compiler! ClojureScript is a hosted language, which means you have to compile it into JavaScript, unless you want to ship the compiler into a browser to be able to interpret ClojureScript at runtime, which is slow and in most cases doesn't make sense (but maybe you wanna build online REPL, that's ok).

This is not going to be easy. ClojureScript sits on top of JavaScript, the compiler is a library written in Clojure, which in turn hosts on JVM. This means you need Java installed, huh.

I prefer to use sdkman to manage my Java installations.

sdk install java

Next step is to install Clojure, head over to installation guide at clojure.org. If the following command returns 2, you are good!

clj -M -e "(inc 1)"

Create project directory somewhere and put deps.edn file into it with the following contents. deps.edn is kind of package.json, if you are coming from JavaScript world.

{:deps {org.clojure/clojurescript {:mvn/version "1.12.42"}}}

I hope you have Node installed? Now we can run ClojureScript REPL in Node environment. This line runs JVM process that loads Clojure, that loads ClojureScript compiler, starts Node process and runs it in REPL mode.

clj -M -m cljs.main --target node --repl

If this runs, it means you are hooked into Node process, nice!

(js/console.log "hello")

Try to list files in the current directory using Node'js fs module.

(def fs (js/require "fs"))
(.readdirSync fs "./")

It works? Great, let's move onto actually compiling a project into JavaScript files. Put our tiny program into src/app/core.cljs file. src is your project's source root directory. Also note that namespace name app.core (that's how modules are called in Clojure) in the code looks exactly like app/core.cljs. That's a convention in Clojure projects: namespace names should reflect directory structure starting from project's source root directory.

(ns app.core)

(println "Howdy!")

Now let's compile the program into Node script

clj -M -m cljs.main --target node --output-dir ./out --compile app.core

and run the script

node out/main.js

Do you see the output? Great, let's stop here and inspect compiler's output. Specified out directory includes whole bunch of files.

ls out

app cljs cljs_deps.js cljsc_opts.edn goog main.js nodejs.js nodejs.js.map nodejscli.js nodejscli.js.map

The actual compiled JavaScript program from your src/app/core.cljs file is in out/app/core.js, let's see what's inside

cat out/app/core.js

// Compiled by ClojureScript 1.12.42 {:target :nodejs, :nodejs-rt true, :optimizations :none}
goog.provide("app.core");
goog.require("cljs.core");
cljs.core.println.call(null, "Howdy!");

//# sourceMappingURL=core.js.map

cljs.core.println.call(null, "Howdy!"); is your (println "Howdy!"), where println is actually a part of implicit cljs.core namespace, which provides stdlib.

goog.provide and goog.require is a part of JavaScript module format of Google's Closure Compiler. Wait, what? Another compiler? Yeah, you see... ClojureScript compiler takes your source and outputs equivalent JavaScript code. Similarly to out/app/core.js, there's also out/cljs/core.js file which is compiled stdlib of ClojureScript. This just means that ClojureScript compiler is a source to source compiler. But how do we bundle all those JavaScript files into production ready bundle?

That's the job of Closure Compiler. Closure is an optimizing JavaScript compiler that ClojureScript is using since its initial release, in 2011. At the time JavaScript didn't have standard module format, remember AMD, UMD, RequireJS and CommonJS? Closure folks at Google invented another one, where goog.provide declares a module and goog.require imports another module.

ClojureScript emits Closure's module format so that the compiler can pick up and optimize generated JavaScript. Putting everything together, that's the stack you have to deal with:

To plug Closure into the equasion and produce optimized JavaScript bundle run the following command.

--optimizations advanced option is what tells Closure to gather all generated JavaScript files into a single bundle and optimize the program by removing unused code. Closure is quite powerful compiler, you can learn more about all kinds of optimizations it performs in this handbook that I created a while ago.

clj -M -m cljs.main --target node --output-dir ./out --optimizations advanced --compile app.core

Output out/main.js file is now a self-contained JavaScript program.

Let's make something cool now. Put the following code into src/app/core.clj

(ns app.core
  (:require [clojure.java.shell :as sh]))

(defmacro version []
  (:out (sh/sh "git" "rev-parse" "--short" "HEAD")))

and update your src/app/core.cljs to

(ns app.core
  (:require-macros [app.core :refer [version]]))

(println "Howdy!" (version))

Now init a git repo in your project directory and make the first commit

git init
git add src
git commit -m "first commit"

Compile your ClojureScript project

clj -M -m cljs.main --target node --output-dir ./out --optimizations advanced --compile app.core

and run it

node out/main.js

The script should print last git commit hash. Now inspect JavaScript generated from src/app/core.cljs

cat out/app/core.js

The hash is embedded in the code!

// Compiled by ClojureScript 1.12.42 {:static-fns true, :optimize-constants true, :target :nodejs, :nodejs-rt true, :optimizations :advanced}
goog.provide("app.core");
goog.require("cljs.core");
goog.require("cljs.core.constants");
cljs.core.println.cljs$core$IFn$_invoke$arity$variadic(
  cljs.core.prim_seq.cljs$core$IFn$_invoke$arity$2(["Howdy!", "7f7e8c3\n"], 0)
);

That's the cool part about Lisps. You can write code in your program that runs at compile time on a program itself. It's almost like a compiler inside of a compiler, except that you don't need special plugins to traverse AST, in Clojure and Lisps in general you create macros, special functions that take code, transform it and return new code.

Now, everything that you learned here is only a part of the story. We haven't touched on the language itself, how real projects are built and how ClojureScript integrates with JavaScript's ecosystem of NPM packages. ClojureScript is definitely not the easiest beast to pick up, but if you are doing front-end development and feel like digging into alternatives and learning from other languages, then there are definitely a few things you can learn from!

JavaScript | Closure

Jose Juarez Junior — Thu, 16 Oct 2025 21:56:41 +0000

Em JavaScript, um closure (ou clausura, em português) é um conceito fundamental que acontece quando uma função “lembra” do ambiente em que foi criada, mesmo depois de esse ambiente ter sido executado.

🧠 Conceito simples:

Um closure é:

“Uma função que tem acesso às variáveis do seu escopo léxico (ou seja, o escopo onde ela foi criada), mesmo depois que esse escopo saiu de execução.”

🔍 Exemplo clássico:

function criarContador() {
  let contador = 0; // variável do escopo da função criarContador

  return function() {
    contador++;              // função interna acessa variável externa
    console.log(contador);
  };
}

const contar = criarContador();

contar(); // 1
contar(); // 2
contar(); // 3

O que está acontecendo aqui:

A função criarContador é executada uma vez.
Ela retorna uma nova função.
Mesmo após criarContador terminar sua execução,
a função retornada ainda tem acesso à variável contador.
Isso é o closure: a função “lembra” do ambiente onde foi criada.

💡 Por que isso é útil?

Closures são usados para:

Encapsulamento e privacidade de dados (como “variáveis privadas”);
Funções que mantêm estado entre chamadas;
Callbacks e event handlers;
Factories e funções geradoras de funções.

JavaFX In Action #21 with Vlad Protsenko, Combining Clojure with JavaFX for Game Development with Defold

Frank Delporte — Thu, 16 Oct 2025 18:16:34 +0000

Vlad Protsenko is a Clojure developer working at Defold. While I initially wanted to learn about the Cljfx project, our conversation evolved into a learning experience: a practical getting-started guide to Clojure, a hands-on demonstration of building JavaFX user interfaces with minimal code, and an inside look at the Defold game engine and its JavaFX-based IDE.

About Vlad

Vlad is a Senior Developer with proficiency in many JVM-based languages. He worked both in very small and large teams, gaining experience in developing projects of various sizes, from scratch and from legacy codebases. He enjoys full-stack development, writing backend, frontend, and Android applications. He started as a game developer and switched to developing enterprise software, currently mixing both at Defold.

You can find him on:

Cljfx Library

Cljfx is a declarative, functional, and extensible wrapper of JavaFX. It's inspired by the better parts of react and re-frame.

Like react, it allows to specify only desired layout, and handles all actual changes underneath. Unlike react (and web in general) it does not impose xml-like structure of everything possibly having multiple children, thus it uses maps instead of hiccup for describing layout.

Like reagent, it allows to specify component descriptions using simple constructs such as data and functions. Unlike reagent, it rejects using multiple stateful reactive atoms for state and instead prefers composing ui in more pure manner.

Like re-frame, it provides an approach to building large applications using subscriptions and events to separate view from logic. Unlike re-frame, it has no hard-coded global state, and subscriptions work on referentially transparent values instead of ever-changing atoms.

Like fn-fx, it wraps underlying JavaFX library so developer can describe everything with clojure data. Unlike fn-fx, it is more dynamic, allowing users to use maps and functions instead of macros and deftypes, and has more explicit and extensible lifecycle for components.

GitHub

Defold Game Editor IDE

Defold is a game engine for high-performance cross-platform games. It comes fully featured out of the box. There's nothing to set up or configure, not even when building. Simply download the editor and get creative! That editor is created with JavaFX and Clojure.

Video content

00:00 Who is Vlad?

00:48 Looking back in time with ActionScript

01:49 About Clojure compared to Scala and Java 21

05:23 About the cljfx project

06:59 Demo of Clojure code and the use of cljfx

12:21 Demo of Defold game editor

15:51 The goal of the cljfx project

16:33 Changes needed in JavaFX

More JFX In Action...

Click here for more posts with JFX In Action videos.