Kotlin.CodeCompared.To/Clojure

Kotlin's println("x") and Clojure's (println "x") contain exactly the same tokens; only the paren slid left. Once the function name is inside the parentheses, arithmetic has to be prefix too — and the compensation is real: there is no precedence table, and (+ 1 2 3 4 5) works because + is a variadic function rather than a binary operator. The cost is that arithmetic-heavy code reads worse than it does in Kotlin. The benefit is that the language has one syntactic form, which is the precondition for macros.

There is no var, and no counter += 1 — a name is bound once to a value, and if you want a different value you bind a different name. let is the workhorse: it is Kotlin's block-scoped val, written as a vector of pairs, with each binding visible to the next. The habit that has to go is the accumulator loop; the habits that replace it (reduce, recur, and rebinding in a new let) are in the Control Flow section. Real, coordinated mutation does exist — see Atoms — but it is a deliberate, named thing rather than the default.

The predicates (integer?, string?, nil?) are ordinary functions, and cond is Kotlin's subject-less when — but nothing verifies that you covered every case, and nothing stops a caller passing a map where you expected a number. In exchange, the edit-run loop collapses: Clojure development is done in a live REPL connected to the running program, where you redefine one function and immediately call it. That is a genuinely different workflow, not a slower one, and it is the thing to try before judging the language. When you do want checks, clojure.spec gives you runtime contracts on data shape — richer than a type system in some ways, and enforced only where you ask for it.

Nothing was declared, and yet the map has value equality, a readable printed form, and a copy() (assoc) — the entire payoff of a data class, with no type. That means every function that works on maps works on your data: merge, select-keys, dissoc, update-in, and every JSON library. The trade is exactly what you would expect: nothing catches (:naem ada), which quietly returns nil instead of failing. Clojure's answer is that shared, generic operations on plain data are worth more than the typo protection, and after a while in a REPL it is hard to argue the point as strongly as you would like to.

A keyword is what Kotlin reaches for an enum or a string to express: a name that is a value. It is interned, so equality is a pointer comparison rather than a string compare; it needs no declaration, so a new one costs nothing; and — the part that makes idiomatic Clojure look the way it does — it is callable, so (:name person) is a lookup and (map :name people) extracts a field from a collection with no lambda at all. Namespaced keywords (:user/name) are how a large codebase keeps keys from colliding, which is the job a type would otherwise do.

This is why Clojure code has so little defensive plumbing: (:name nil) is nil, (count nil) is 0, (map f nil) is empty, so a chain of lookups over missing data flows through instead of exploding. or is your Elvis operator, and note the falsy rule — only nil and false are false, so 0 and "" are truthy, which is the opposite of the mistake a JavaScript refugee makes. What nil punning cannot save you from is Java interop: call a method on nil and you get the NullPointerException Kotlin was protecting you from all along. It is a library convention, not a guarantee.

Default arguments become multiple arities — a function is a set of implementations chosen by argument count, and the short one usually calls the long one, which is the same telescoping pattern Java forces but written in one form. Named arguments do not exist at all, and the idiomatic replacement is better than it sounds: take a single map and destructure it in the parameter list with :keys and :or, and the call site reads exactly like Kotlin's named arguments with defaults. That pattern is everywhere in Clojure libraries.

% is it, and #(…) is the trailing-lambda shorthand — but notice the last block, which is the real lesson. Because everything is a plain function and the library is built out of small ones (inc, even?, +), a huge fraction of Clojure lambdas turn out to be unnecessary: you pass the function by name. The habit to build is to look for an existing function before writing #(…). One rule to know: #() cannot be nested, because there would be no way to say which % you meant.

Kotlin can express all of this with lambdas, but it has no comp, no partial, and no apply in the standard library, so each one is a hand-written closure. Having them as functions matters more than it looks: (partial * 3) is a value you can store in a map, put in a list, and pass on, and comp lets you build a pipeline without naming any of the intermediate steps. Remember that comp runs right to left (like mathematics, unlike a threading macro) — which is exactly why the threading macros in the next section exist.

Method chaining is gone, because there are no methods: map and filter are functions that take the collection as their last argument, which makes the nesting read inside-out (the filter above happens first, despite appearing second). That is unreadable at three levels deep, and the next concept — the threading macro — exists precisely to fix it. What you gain is uniformity: one map works over vectors, lists, sets, maps and lazy sequences, so there is no Iterable/Sequence/Stream split and no method that exists on one type but not another.

The threading macros restore left-to-right reading order, and they are the closest thing Clojure has to Kotlin's dot chain. Two of them, because argument position matters: ->> puts the value last (which is where the sequence functions want it) and -> puts it first (which is where the map functions want it). some-> short-circuits on nil and is a direct replacement for a ?. chain. And here is the part worth pausing on: none of these are language features. They are ordinary macros, defined in the standard library in a few lines, which anyone could have written — and that is the argument for the Macros section below.

Immutability here is not a discipline you maintain but the substrate you stand on: conj and assoc return new collections that share structure with the originals, so copying a large map to change one key is O(log₃₂ n) rather than O(n), and no two threads can ever see a torn value. That is what makes the concurrency story so simple later on. The everyday payoff, though, is update-in / assoc-in / get-in: reaching into nested data with a path vector is one call, where Kotlin's immutable version needs nested copy() calls and its mutable version needs the cast in the left column.

Laziness is the default rather than an asSequence() opt-in, so map over a million elements costs nothing until something realizes it — and infinite sequences ((range), (iterate f x), (cycle …)) are ordinary values you can pass around. The trap is the mirror image of Kotlin's: because nothing runs until it is forced, a map whose function has a side effect may run later than you think, in a different context, or never — which is why the example needs doall to force it, and why side-effecting work belongs in doseq or run! rather than map. Lazy sequences also cache, so realizing one twice does the work once.

Kotlin's single when splits into three: case for constant dispatch (fast, but no ranges or guards — and note it does not fall through to cond-style tests), cond for arbitrary conditions, and if for the two-branch expression. when in Clojure is not Kotlin's when — it is an if with no else and a multi-form body, which is a false friend worth burning in early. What is missing is exhaustiveness: nothing checks that your cond covered every case, and a cond that matches nothing returns nil rather than failing.

Note that Clojure's for is a false friend twice over: it is not a loop, it does not iterate for effect, and it returns a lazy sequence — it is a list comprehension, with :when and :let modifiers. The loop you actually want is almost always reduce. When you genuinely need explicit iteration with carried state, loop/recur is it: recur rebinds the loop variables and jumps, reusing the stack frame, which is how Clojure gets tail recursion on a JVM that does not have it. Forgetting recur and calling the function by name instead is the classic beginner's stack overflow.

Kotlin's destructuring is positional and works only where componentN exists, so a map — the thing you will be holding constantly in Clojure — cannot be destructured at all. Clojure's is by key, comes with defaults (:or), can keep the whole value (:as), nests to any depth, and works anywhere a binding form appears: in let, in a defn parameter list, in a for, in a doseq. Destructuring a map in the parameter list is the standard way to write a function that takes options, and it is the direct substitute for the named arguments Clojure does not have.

Positional destructuring works on any sequential thing — a vector, a list, a lazy sequence, a string, a map entry — with & collecting the rest and _ discarding what you do not need. Kotlin's equivalent works only on types that implement componentN, which in practice means data classes and pairs, so a plain List has to be taken apart with first() and drop(1). Combined with the map destructuring above, this is one uniform binding language that appears in every position that binds a name — and there is only one to learn.

A defrecord is close to a Kotlin data class — value equality, keyword access, assoc — and it can implement protocols, which is where the type-based dispatch comes from. The differences worth knowing: a protocol has no default methods, so describe becomes an ordinary function rather than an interface member (which is arguably cleaner — it can be extended without touching the protocol); and protocols can be extended to types you do not own, including String and nil, with extend-type. That last part is the type-class-shaped hole Kotlin fills with extension functions, except that a protocol dispatches dynamically on the value's actual type, so it works through a collection of mixed types.

Kotlin's when (event) over a sealed hierarchy is closed — the compiler guarantees you handled every case, and the price is that adding a case means editing that when, in the file that owns it. A multimethod is open: the dispatch function can be anything (a keyword, a computed classification, a vector of two argument types for double dispatch), and a new implementation can be added from another namespace, later, by someone who does not control the original. That solves the expression problem in the direction Kotlin cannot, and it gives up exactly what you would expect: nothing tells you a case is missing, and :default is the only safety net.

swap! takes a function, not a value: it reads the current value, applies your function, and compare-and-swaps the result in, retrying if someone else got there first. Because the value inside is immutable, that retry is always safe — there is no half-updated state to observe, no lock to take, and no @Volatile or synchronized to remember. That is the whole concurrency story for most Clojure programs, and it is the direct payoff of persistent data structures. The rule that follows: your function must be pure, since a retry will run it again — a swap! whose function prints or writes to a database is a bug waiting for contention.

This is the argument for the whole paradigm, and it is worth taking seriously: because no collection can be mutated, the concept of a data race over your program's data mostly ceases to exist. There is no synchronized, no lock ordering, no defensive copy before handing a list to another thread, and no @Volatile. Kotlin gives you excellent tools for managing shared mutable state (coroutines, Mutex, immutable data classes by convention) — but they are tools for a problem Clojure declined to have. What Clojure gives up is in-place performance: a tight numeric loop mutating an array is genuinely faster in Kotlin, and Clojure's answer (transients, primitive arrays, type hints) is an opt-in escape hatch you use in the 1% of code that needs it.

Look at what spy did: it received (+ 1 2) as a three-element list, kept a copy to print, and emitted new code that evaluates it and reports it. Kotlin cannot do that at any level — an inline function taking a lambda gets close to a new control structure (which is exactly what run, apply and synchronized are), but the body arrives as a lambda, not as source you can read, take apart, or rewrite. That is the whole difference: in Clojure, features like ->, when, cond, defn itself, and async/await-style syntax (core.async's go block) are library code, written by users, needing no change to the language. In Kotlin each of those is a compiler feature you wait for.

This is what "code is data" actually means: (+ 1 (* 2 3)) is a list whose first element is a symbol, so first, rest, map and count work on your program exactly as they work on any other list. That is the property that makes macros ordinary rather than magical, and it is the reason Lisp has no syntax to speak of — the uniform parenthesized form is the price of admission, and macros are what you buy with it. Kotlin's source is text with a grammar; by run time the tree is gone, and rewriting it means writing a compiler plugin against an internal API. Whether the trade is worth it is the oldest argument in programming, and this page will not settle it — but you should know precisely what is being traded.

The shape is familiar — try is an expression, as in Kotlin, and there are no checked exceptions — but ex-info is the idiom worth stealing conceptually. Instead of declaring an exception class per failure mode, you throw a message plus an arbitrary map, and the handler pulls that map back out with ex-data and destructures it. Failure information becomes data you can pattern-match on, filter, log as JSON, or pass across a boundary, rather than a type hierarchy you have to design in advance. The catch clause here is written (catch :default …), which is the ClojureScript catch-all; on the JVM you would write the class name, and that difference is one of the few real gaps between the two runtimes.

The {:pre …} / {:post …} map is a small feature with a nice property: it is part of the function's definition rather than its body, so it reads as a contract, and % in a :post condition is the return value. Unlike Dart's assert, these run in production by default (they can be compiled out with *assert*, but the default is on), so they behave like Kotlin's require. For serious contracts on data shape rather than on a single value, the real tool is clojure.spec: it describes the structure of a map, validates it, explains failures in detail, and generates test data from the same description — a checking story with no Kotlin equivalent, precisely because Kotlin gets some of it from the type system instead.

Interop is deliberately unglamorous: (.method object args), (Class/staticMethod args), (Class. args) for a constructor, and doto when you have to call several mutating methods on the same object. Everything in the JVM ecosystem is reachable, which is the pragmatic argument for Clojure over other Lisps. Two cautions carry over from Kotlin's platform types: Java methods return real null, and the nil-punning that makes Clojure so forgiving does not apply to a method call on nil — that is a NullPointerException, same as ever. And a Java collection is mutable, so wrap it in a Clojure collection ((into [] javaList)) at the boundary rather than passing it around.