Jun 27, 2025·8 min
Rich Hickey & Clojure: Simplicity, Immutability, Better Defaults
An accessible look at Rich Hickey’s Clojure ideas: simplicity, immutability, and better defaults—practical lessons for building calmer, safer complex systems.
An accessible look at Rich Hickey’s Clojure ideas: simplicity, immutability, and better defaults—practical lessons for building calmer, safer complex systems.
Software rarely becomes complicated all at once. It gets there one “reasonable” decision at a time: a quick cache to hit a deadline, a shared mutable object to avoid copying, an exception to the rules because “this one is special.” Each choice looks small, but together they create a system where changes feel risky, bugs are hard to reproduce, and adding features starts taking longer than building them.
Complexity wins because it offers short-term comfort. It’s often faster to wire in a new dependency than to simplify an existing one. It’s easier to patch state than to ask why state is spread across five services. And it’s tempting to rely on conventions and tribal knowledge when the system grows faster than the documentation.
This isn’t a Clojure tutorial, and you don’t need to know Clojure to get value from it. The goal is to borrow a set of practical ideas often associated with Rich Hickey’s work—ideas you can apply to everyday engineering decisions, regardless of language.
Most complexity isn’t created by the code you write deliberately; it’s created by what your tools make easy by default. If the default is “mutable objects everywhere,” you’ll end up with hidden coupling. If the default is “state lives in memory,” you’ll struggle with debugging and traceability. Defaults shape habits, and habits shape systems.
We’ll focus on three themes:
These ideas don’t remove complexity from your domain, but they can stop your software from multiplying it.
Rich Hickey is a long-time software developer and designer best known for creating Clojure and for talks that challenge common programming habits. His focus isn’t trend-chasing—it’s the recurring reasons systems become hard to change, hard to reason about, and hard to trust once they grow.
Clojure is a modern programming language that runs on well-known platforms like the JVM (Java’s runtime) and JavaScript. It’s designed to work with existing ecosystems while encouraging a specific style: represent information as plain data, prefer values that don’t change, and keep “what happened” separate from “what you show on screen.”
You can think of it as a language that nudges you toward clearer building blocks and away from hidden side effects.
Clojure wasn’t created to make small scripts shorter. It was aimed at recurring project pain:
Clojure’s defaults push toward fewer moving parts: stable data structures, explicit updates, and tools that make coordination safer.
The value isn’t limited to switching languages. Hickey’s core ideas—simplify by removing needless interdependencies, treat data as durable facts, and minimize mutable state—can improve systems in Java, Python, JavaScript, and beyond.
Rich Hickey draws a sharp line between simple and easy—and it’s a line most projects cross without noticing.
Easy is about how something feels right now. Simple is about how many parts it has and how tightly they’re entangled.
In software, “easy” often means “quick to type today,” while “simple” means “harder to break next month.”
Teams often choose shortcuts that reduce immediate friction but add invisible structure that must be maintained:
Each choice may feel like speed, but it increases the number of moving parts, special cases, and cross-dependencies. That’s how systems become fragile without any single dramatic mistake.
Shipping fast can be great—but speed without simplifying usually means you’re borrowing against the future. The interest shows up as bugs that are hard to reproduce, onboarding that drags, and changes that require “careful coordination.”
Ask these questions when reviewing a design or PR:
“State” is simply the stuff in your system that can change: a user’s shopping cart, an account balance, the current configuration, what step a workflow is on. The tricky part isn’t that change exists—it’s that every change creates a new opportunity for things to disagree.
When people say “state causes bugs,” they usually mean this: if the same piece of information can be different at different times (or in different places), then your code has to constantly answer, “Which version is the real one right now?” Getting that answer wrong produces errors that feel random.
Mutability means an object is edited in place: the “same” thing becomes different over time. That sounds efficient, but it makes reasoning harder because you can’t rely on what you saw a moment ago.
A relatable example is a shared spreadsheet or document. If multiple people can edit the same cells at the same time, your understanding can be invalidated instantly: totals change, formulas break, or a row disappears because someone reorganized it. Even if nobody is doing anything malicious, the shared, editable nature is what creates confusion.
Software state behaves the same way. If two parts of a system read the same mutable value, one part can silently change it while the other continues with an outdated assumption.
Mutable state turns debugging into archaeology. A bug report rarely tells you “the data was changed incorrectly at 10:14:03.” You just see the end result: a wrong number, an unexpected status, a request that fails only sometimes.
Because state changes over time, the most important question becomes: what sequence of edits led here? If you can’t reconstruct that history, behavior becomes unpredictable:
This is why Hickey treats state as a complexity multiplier: once data is both shared and mutable, the number of possible interactions grows faster than your ability to keep them straight.
Immutability simply means data that doesn’t change after it’s created. Instead of taking an existing piece of information and editing it in place, you create a new piece of information that reflects the update.
Think of a receipt: once printed, you don’t erase line items and rewrite totals. If something changes, you issue a corrected receipt. The old one still exists, and the new one is clearly “the latest version.”
When data can’t be quietly modified, you stop worrying about invisible edits happening behind your back. That makes everyday reasoning much easier:
This is a big part of why Hickey talks about simplicity: fewer hidden side effects means fewer mental branches to track.
Creating new versions can sound wasteful until you compare it to the alternative. Editing in place can leave you asking: “Who changed this? When? What was it before?” With immutable data, changes are explicit: a new version exists, and the old one remains available for debugging, auditing, or rollback.
Clojure leans into this by making it natural to treat updates as producing new values, not mutations of old ones.
Immutability isn’t free. You may allocate more objects, and teams used to “just update the thing” may need time to adjust. The good news is that modern implementations often share structure under the hood to reduce memory cost, and the payoff is typically calmer systems with fewer hard-to-explain incidents.
Concurrency is just “many things happening at once.” A web app handling thousands of requests, a payment system updating balances while generating receipts, or a mobile app syncing in the background—all of these are concurrent.
The tricky part isn’t that multiple things happen. It’s that they often touch the same data.
When two workers can both read and then modify the same value, the final result can depend on timing. That’s a race condition: not a bug you can reproduce easily, but a bug that appears when the system is busy.
Example: two requests try to update an order total.
Nothing “crashed,” but you lost an update. Under load, these timing windows become more common.
Traditional fixes—locks, synchronized blocks, careful ordering—work, but they force everyone to coordinate. Coordination is expensive: it slows throughput and becomes fragile as the codebase grows.
With immutable data, a value doesn’t get edited in place. Instead, you create a new value that represents the change.
That single shift removes a whole category of problems:
Immutability doesn’t make concurrency free—you still need rules for which version is current. But it makes concurrent programs far more predictable, because the data itself isn’t a moving target. When traffic spikes or background jobs pile up, you’re less likely to see mysterious, timing-dependent failures.
“Better defaults” means the safer choice happens automatically, and you only take on extra risk when you explicitly opt out.
That sounds small, but defaults quietly guide what people write on a Monday morning, what reviewers accept on a Friday afternoon, and what a new teammate learns from the first codebase they touch.
A “better default” isn’t about making every decision for you. It’s about making the common path less error-prone.
For example:
None of these eliminate complexity, but they keep it from spreading.
Teams don’t just follow documentation—they follow what the code “wants” you to do.
When mutating shared state is easy, it becomes a normal shortcut, and reviewers end up debating intent: “Is this safe here?” When immutability and pure functions are the default, reviewers can focus on logic and correctness, because the risky moves stand out.
In other words, better defaults create a healthier baseline: most changes look consistent, and unusual patterns are obvious enough to question.
Long-term maintenance is mostly about reading and changing existing code safely.
Better defaults help new teammates ramp up because there are fewer hidden rules (“be careful, this function secretly updates that global map”). The system becomes easier to reason about, which lowers the cost of every future feature, fix, and refactor.
A useful mental shift in Hickey’s talks is to separate facts (what happened) from views (what we currently believe to be true). Most systems blur these together by storing only the latest value—overwriting yesterday with today—and that makes time disappear.
A fact is an immutable record: “Order #4821 was placed at 10:14,” “Payment succeeded,” “Address was changed.” These don’t get edited; you add new facts as reality changes.
A view is what your app needs right now: “What’s the current shipping address?” or “What’s the customer’s balance?” Views can be recomputed from facts, cached, indexed, or materialized for speed.
When you retain facts, you gain:
Overwriting records is like updating a spreadsheet cell: you only see the latest number.
An append-only log is like a checkbook register: each entry is a fact, and the “current balance” is a view computed from the entries.
You don’t have to adopt a full event-sourced architecture to benefit. Many teams start smaller: keep an append-only audit table for critical changes, store immutable “change events” for a few high-risk workflows, or retain snapshots plus a short history window. The key is the habit: treat facts as durable, and treat current state as a convenient projection.
One of Hickey’s most practical ideas is data first: treat your system’s information as plain values (facts), and treat behavior as something you run against those values.
Data is durable. If you store clear, self-contained information, you can reinterpret it later, move it between services, reindex it, audit it, or feed it into new features. Behavior is less durable—code changes, assumptions change, dependencies change.
When you mix these together, systems get sticky: you can’t reuse data without dragging along the behavior that created it.
Separating facts from actions reduces coupling because components can agree on a data shape without agreeing on a shared codepath.
A reporting job, a support tool, and a billing service can all consume the same order data, each applying its own logic. If you embed logic inside the stored representation, every consumer becomes dependent on that embedded logic—and changing it becomes risky.
Clean data (easy to evolve):
{
"type": "discount",
"code": "WELCOME10",
"percent": 10,
"valid_until": "2026-01-31"
}
Mini-programs in storage (hard to evolve):
{
"type": "discount",
"rule": "if (customer.orders == 0) return total * 0.9; else return total;"
}
The second version looks flexible, but it pushes complexity into the data layer: you now need a safe evaluator, versioning rules, security boundaries, debugging tools, and a migration plan when that rule language changes.
When stored information stays simple and explicit, you can change behavior over time without rewriting history. Old records remain readable. New services can be added without “understanding” legacy execution rules. And you can introduce new interpretations—new UI views, new pricing strategies, new analytics—by writing new code, not by mutating what your data means.
Most enterprise systems don’t fail because one module is “bad.” They fail because everything is connected to everything else.
Tight coupling shows up as “small” changes that trigger weeks of retesting. A field added to one service breaks three downstream consumers. A shared database schema becomes a coordination bottleneck. A single mutable cache or singleton “config” object quietly becomes a dependency of half the codebase.
Cascading change is the natural result: when many parts share the same changing thing, the blast radius expands. Teams respond by adding more process, more rules, and more handoffs—often making delivery even slower.
You can apply Hickey’s ideas without switching languages or rewriting everything:
When data doesn’t change under your feet, you spend less time debugging “how did it get into this state?” and more time reasoning about what the code does.
Defaults are where inconsistency sneaks in: each team invents its own timestamp format, error shape, retry policy, and concurrency approach.
Better defaults look like: versioned event schemas, standard immutable DTOs, clear ownership of writes, and a small set of blessed libraries for serialization, validation, and tracing. The result is fewer surprise integrations and fewer one-off fixes.
Start where change is already happening:
This approach improves reliability and team coordination while keeping the system running—and keeps the scope small enough to finish.
It’s easier to apply these ideas when your workflow supports fast, low-risk iteration. For example, if you’re building new features in Koder.ai (a chat-based vibe-coding platform for web, backend, and mobile apps), two features map directly onto the “better defaults” mindset:
Even if your stack is React + Go + PostgreSQL (or Flutter for mobile), the core point remains the same: the tools you use every day quietly teach a default way of working. Choosing tools that make traceability, rollback, and explicit planning routine can reduce the pressure to “just patch it” in the moment.
Simplicity and immutability are powerful defaults, not moral rules. They reduce the number of things that can unexpectedly change, which helps when systems grow. But real projects have budgets, deadlines, and constraints—and sometimes mutability is the right tool.
Mutability can be a practical choice in performance hotspots (tight loops, high-throughput parsing, graphics, numeric work) where allocations dominate. It can also be fine when the scope is controlled: local variables inside a function, a private cache hidden behind an interface, or a single-threaded component with clear boundaries.
The key is containment. If the “mutable thing” never leaks out, it can’t spread complexity across the codebase.
Even in a mostly functional style, teams still need clear ownership:
This is where Clojure’s bias toward data and explicit boundaries helps, but the discipline is architectural, not language-specific.
No language fixes poor requirements, an unclear domain model, or a team that can’t agree on what “done” means. Immutability won’t make a confusing workflow understandable, and “functional” code can still encode the wrong business rules—just more neatly.
If your system is already in production, don’t treat these ideas as an all-or-nothing rewrite. Look for the smallest move that lowers risk:
The goal isn’t purity—it’s fewer surprises per change.
This is a sprint-sized checklist you can apply without changing languages, frameworks, or team structure.
Look for material on simplicity vs ease, managing state, value-oriented design, immutability, and how “history” (facts over time) helps debugging and operations.
Simplicity isn’t a feature you bolt on—it’s a strategy you practice in small, repeatable choices.
Complexity accumulates through small, locally reasonable decisions (extra flags, caches, exceptions, shared helpers) that add modes and coupling.
A good signal is when a “small change” requires coordinated edits across multiple modules or services, or when reviewers must rely on tribal knowledge to judge safety.
Because shortcuts optimize for today’s friction (time-to-ship) while pushing costs into the future: debugging time, coordination overhead, and change risk.
A useful habit is to ask in design/PR review: “What new moving parts or special cases does this introduce, and who will maintain them?”
Defaults shape what engineers do under pressure. If mutation is the default, shared state spreads. If “in-memory is fine” is the default, traceability disappears.
Improve defaults by making the safe path the path of least resistance: immutable data at boundaries, explicit timezones/nulls/retries, and well-defined state ownership.
State is anything that changes over time. The hard part is that change creates opportunities for disagreement: two components can hold different “current” values.
Bugs show up as timing-dependent behavior (“works locally,” flaky production issues) because the question becomes: which version of the data did we act on?
Immutability means you don’t edit a value in place; you create a new value that represents the update.
Practically, it helps because:
Not always. Mutability can be a good tool when it’s contained:
The key rule: don’t let mutable structures leak across boundaries where many parts can read/write them.
Race conditions typically come from shared, mutable data being read and then written by multiple workers.
Immutability reduces the surface area of coordination because writers produce new versions instead of editing a shared object. You still need a rule for publishing the current version, but the data itself stops being a moving target.
Treat facts as append-only records of what happened (events), and treat “current state” as a view derived from those facts.
You can start small without full event sourcing:
Store information as plain, explicit data (values), and run behavior against it. Avoid embedding executable rules inside stored records.
This makes systems more evolvable because:
Pick one workflow that changes often and apply three steps:
Measure success by fewer flaky bugs, smaller blast radius per change, and less “careful coordination” in releases.
Make your “data shapes” immutable by default. Treat request/response objects, events, and messages as values you create once and never modify. If something must change, create a new version.
Prefer pure functions in the middle of workflows. Start with one workflow (e.g., pricing, permissions, checkout) and refactor the core into functions that take data in and return data out—no hidden reads/writes.
Move state to fewer, clearer places. Pick one source of truth per concept (customer status, feature flags, inventory). If multiple modules keep their own copies, make that an explicit decision with a sync strategy.
Add an append-only log for key facts. For one domain area, record “what happened” as durable events (even if you still store current state). This improves traceability and reduces guesswork.
Define safer defaults in APIs. Defaults should minimize surprising behavior: explicit timezones, explicit null handling, explicit retries, explicit ordering guarantees.