dmx-fun

Every functional programming pitch eventually collides with a senior engineer saying 'just use exceptions.' That advice is not ignorance — exceptions win real trade-offs, and there are cases where they are genuinely the right tool. Here is an honest map of where each belongs.

Functional thinking is not about monads or category theory. For backend engineers it is a practical shift: model the things a service actually deals with — missing rows, failed calls, invalid input, side effects — as ordinary values you can pass, compose, and let the compiler check.

DDD is often taught with rich objects and mutable aggregates, while functional programming preaches immutability and pure functions. The tension is real on the surface — but the tactical patterns of DDD and the tools of FP turn out to be the same idea from two directions. Here is where they meet.

0.2.0 is dmx-fun's first-anniversary release: two new reactive modules — fun-reactor (Project Reactor interop) and fun-spring-webflux (Spring WebFlux adapters) — plus a year of 17 releases building a functional programming ecosystem for Java backends.

Most error handling reports the first failure and stops. A registration form, an API request, a config file — these need every problem at once, not one round-trip per mistake. Validated is the type that collects all errors instead of ... [More] short-circuiting, and the reason it works comes down to one deep idea: independent checks compose differently from dependent ones. [Less]

Java developers use closures every time they write a lambda that references a variable from the surrounding method — usually without naming what they are doing. This post explains what a closure actually is, what 'effectively final' really means and why the rule exists, and the capture pitfalls that bite people in loops and shared state.

Retry loops, timeouts, and backoff usually arrive as tangled imperative code or a heavy resilience framework. There is a lighter option: model each policy as a function that wraps a function. Once retry, timeout, and backoff are ordinary higher-order functions, they compose — and you can read a call's full resilience behavior in one line.

Most developers learn functional programming in the wrong order — starting with monads and category theory instead of the habits that actually change their code. This is a staged path that starts with pure functions and immutability, then adds types, then composition, building each skill on the one before it.

Four libraries, four languages, one recurring motivation. Vavr, Arrow, Cats, and fp-ts exist because mainstream languages gave developers functional building blocks but left out the types that make them safe. This post maps what each library actually provides — and what gap in the host language each one fills.

A pure function always returns the same output for the same input and changes nothing in the world around it. That single rule — predictable output, no hidden changes — is the foundation that makes functional code easier to test, reason about, and refactor.