✍️ 필사 모드: Functional Languages in 2026 — A Camp-by-Camp Survey of Haskell, OCaml, Elm, Gleam, Roc, Unison, Lean 4, F#, Clojure

• Prologue — Why another functional map
• 1. One word, five very different universes
• 2. Family vs trait matrix
• 3. The ML family — Jane Street is carrying OCaml in 2026
• 4. The Haskell family — anchors firmer, learners fewer
• 5. The BEAM family — most alive, with an internal split
• 6. The Lisp family — Clojure for enterprise, Racket for teaching, CL as living museum
• 7. The new line — Roc, Unison, Lean 4, Koka and their different bets
• 8. Functional but pragmatic — what the Effect-TS / fp-ts merger means
• 8.5. The same task in five families — one page of code
• 8.6. Scorecard — hiring, tooling, ecosystem per family
• 9. Is picking a functional language for a 2026 startup rational
• 9.5. A short hiring guide per family — can you fill the team in six months
• 9.6. Functional ideas already leaked into the mainstream
• 10. If you had to pick one — killer feature per family in one line
• Epilogue — A checklist for the next decision
• References

Prologue — Why another functional map

This blog already has a deep dive on Erlang/Elixir and the actor model, a long piece unpacking monads in Haskell, and separate posts on Effect-TS and Gleam. All of those were maps inside a single family. As of May 2026 it is worth stepping back once and looking at the whole landscape from above. While the ML family moves onto OCaml 5 under Jane Street's lead, the Haskell family is being carried by Mercury and Standard Chartered, the BEAM family ships Gleam 1.16 in regular minor releases, and a new line — Roc, Unison, Lean 4, Koka — places very different bets. If you only look at one family at a time you will misjudge which language is alive.

This post does not drill into any single family. It places every family on the same ruler and asks the same six questions of each.

1. Who actually uses it in 2026
2. What is growing and what is fading
3. If you had to pick one, what is its killer feature
4. Is hiring possible, are libraries adequate
5. When is picking it rational
6. When is picking it irrational

One-line core. Functional languages are not "losing users" — the weight between families is being rebalanced. In 2026 the BEAM family is the most alive, the ML family quietly grows inside infrastructure, the Haskell family has fewer learners but stronger production anchors, Elm is frozen, and Roc and Lamdera have moved into the space Elm left.

Prices and version numbers move fast. The numbers below are as of May 2026. The structure should still hold six months from now.

1. One word, five very different universes

First, the big picture. "Functional language" sounds like one tribe, but five families actually live separately and rarely talk to each other.

The ML family started in 1973 at Edinburgh. Standard ML, OCaml, ReScript, ReasonML, F#. Its signature traits are strict evaluation, a module system, and a functional core with pragmatic side effects. Hindley-Milner type inference originated here. This is the quietest production family — more engineering than academia.

The Haskell family branched off in 1990 with Haskell 1.0. Haskell, PureScript, Elm, Idris, Idris2, Agda. Traits: lazy evaluation, monadic effects, uncompromising purity. Strongly tied to academia, concentrated in fintech anchors in industry.

The BEAM family started in 1986 at Ericsson with Erlang. Erlang, Elixir, Gleam. Traits: actor model, let it crash, distribution and fault tolerance. Functional with an internal split — "types or dynamic". Strongest in messaging, telecom, real-time systems.

The Lisp family is the oldest line, from 1958. Common Lisp, Scheme, Racket, Clojure, ClojureScript. Traits: homoiconicity (code is data) and REPL-driven development. Bigger than just functional, but modern Lisps actively encourage functional style.

The new line started after the mid-2010s. Roc (alpha since 2022), Unison (1.0 in 2025), Lean 4 (theorem prover that grew into a systems language), Koka (Microsoft Research). Traits: algebraic effects, content-addressable code, dependent types as a tool, memory model innovation. Almost no industry hiring, but the research and enthusiast communities are very active.

What all five share is first-class functions, immutable-by-default data, algebraic data types, and pattern matching. Beyond that the design philosophies, community cultures, and hiring markets diverge. Advice that works in one family does not transfer to another.

2. Family vs trait matrix

To keep the comparison tractable, here are six axes laid across the families.

If you reread this table once a week you can quickly tell which families are alive and which are museums. The next sections open each family one by one.

3. The ML family — Jane Street is carrying OCaml in 2026

The key 2026 event in the ML family is simple. Jane Street moved its production servers onto the OCaml 5 runtime. Yaron Minsky announced this at ICFP/SPLASH 2025 and the company blog confirmed it. Systems trading trillions of dollars now run on OCaml 5. It is the strongest possible signal for the family. Without lazy evaluation, without monadic tracking, functional code holds up under heavy industrial weight.

OCaml in May 2026 ships 5.4.x on the stable line, with 4.x LTS still alive in maintenance. 5.4 reached full feature parity with the 4.x line, and the effect handlers that came with the multicore runtime (Eio) are now everyday tools. Jane Street operates its own compiler fork called OxCaml. It carries modal types, ownership, parallelism extensions, and some of that work is flowing back upstream. In other words, "bringing Rust ownership into OCaml" is being attempted in real production at the same time as the language committee evolves the base.

If you must pick one OCaml killer feature it is the module system. Where other functional languages build abstractions out of function composition, OCaml builds them out of functors — modules that take modules and return modules. For organizing a large codebase there is nothing else quite like it. That alone is why Jane Street cannot leave.

F# shipped F# 10 alongside .NET 10 in November 2025. The release is about clarity, consistency, IDE responsiveness, and parallel compilation rather than dramatic features. Production use is scattered. Some UK and Nordic finance shops, some game tooling, some domain modeling work inside .NET enterprise apps. It is the natural ramp for C# developers attempting functional thinking. Microsoft does not market it heavily, but does not kill it. Stable museum is the right phrase.

ReScript / ReasonML split. ReasonML was effectively absorbed into ReScript, and ReScript survives in a narrow slice of the React world. Some Japanese companies and US startups operate large ReScript codebases. The catch is that TypeScript moved hard between 2023 and 2025 — satisfies operator, const generics, Effect-TS — which cut into ReScript's pitch. Picking ReScript for a new project needs a strong reason in 2026.

When is the ML family rational. First, when you need to organize a large functional codebase (OCaml functors). Second, when you want crisp domain modeling inside .NET (F#). Third, when you want a fast native single binary without JIT or runtime overhead (OCaml). It is irrational when you pick "the ML family for front end" without checking hiring and libraries. ReScript is a narrow bet in 2026.

4. The Haskell family — anchors firmer, learners fewer

The Haskell family in 2026 splits into two clear directions. Anchors are firmer, learners are fewer.

On the anchor side Mercury is the most visible name. Mercury is a US business-banking startup serving more than 300,000 businesses with around 248 billion USD of transaction volume in 2025 on roughly 650 million USD annualized revenue. Its codebase is around 2 million lines of Haskell. The Mercury engineering write-up on blog.haskell.org, titled "A Couple Million Lines of Haskell", confirmed those numbers. Their core claim is striking. Most of their engineers had never written a line of Haskell before joining. So Haskell is no longer the language of "genius PhDs" — industrial cases now show ordinary developers learning and using it.

Standard Chartered continues to maintain its core quant library Cortex in Mu/Haskell. About 6.5 million lines of code, powering price and risk engines across all asset classes, from server-side batches handling millions of trades a day to desktop GUIs. The same language goes top to bottom. Anduril, Juspay and others run Haskell in parts of their core. Well-Typed (the Haskell consultancy) confirmed these relationships in their Q1 2026 ecosystem report.

GHC continues a quarterly release cadence in 2026. GHC 9.x is the stable line, 10.x is in RC. Cabal and stack coexist. The action is in compiler modularity, typed Template Haskell, and the production reach of linear types. The effects library landscape settled into effectful, polysemy, and fused-effects; new code mostly chooses effectful.

If you must pick one Haskell killer feature it is the type system tracking side effects. The moment a function signature carries the IO type (only ever inside code fences here), the compiler tells you it touches the outside world. The absence of that type is purity. That single rule makes large-codebase refactors much less scary.

Elm is the most complicated position in the family. 0.19.1 has effectively been frozen since 2019. Evan Czaplicki is working on other things, the official repository moves very slowly, and the gap is being filled by two efforts. First, Lamdera — a commercial fork that extends Elm into full-stack territory, with one model spanning server and client and clean migrations. Second, community projects like elm-pages and gren-lang. Still, recommending Elm as the default for a new front end is hard in 2026. The existing codebases still run beautifully. New codebases now have natural successors, and Roc is the most direct.

PureScript is alive. The compiler is actively improved and Halogen still works. But the community itself has shifted to "recommend React to newcomers". PureScript is only rational for a very narrow desire — "I want Haskell on JS". For most teams React with Effect-TS is the better path.

Idris2 is the most serious attempt to bring dependent types to industry. Edwin Brady's Type-Driven Development with Idris remains the standard text. As of May 2026 industrial hiring is effectively zero, with research labs and enthusiast projects keeping it alive. The ideas — types as specifications — still leak into other languages (Haskell linear types, Rust const generics, TypeScript template literal types).

When is the Haskell family rational. First, fintech with complex business rules where types enforce invariants. Second, compilers, static analyzers, domain DSLs. Third, large codebases maintained by small teams (Mercury's core claim). Irrational when you pick "front end + Elm + new project", or when you adopt the language based on one PhD's enthusiasm without a hiring plan.

5. The BEAM family — most alive, with an internal split

The BEAM family is the most active functional family in 2026. The reason is plain. Demand for distribution and fault tolerance has not dropped, and no other runtime solves those problems as cleanly. Inside the family there is a tension. Static types or stay dynamic.

Erlang still runs. WhatsApp's backend remains Erlang at its core, RabbitMQ, ejabberd and CouchDB run on it and are all actively maintained in 2026. OTP 27 and 28 are stable. New teams rarely pick Erlang from scratch, but existing Erlang systems are not bleeding people either. It is the "stable preserved zone" of the family.

Elixir carries the family's energy. In 2024 Jose Valim opened serious work on set-theoretic types, and the 1.18 and 1.19 lines gradually rolled out gradual typing inference. So a language that started dynamic on BEAM is moving toward static typing through a different door. Phoenix LiveView holds a 1.x stable line in 2026, and together with Phoenix 1.8 it is the canonical example of Server-Driven UI. Fly.io operates part of its infrastructure on LiveView. Discord uses Elixir for message routing. Pinterest, Bleacher Report, PepsiCo run Elixir for parts of their services.

If you must pick one Elixir killer feature it is OTP fault tolerance. Supervisor trees, links, monitors, restart strategies. Once these four meet, the property "if one part dies the whole system survives" is enforced at the code level. For a team that must build distributed systems with reliability from day one there is little that compares.

Gleam is the family's rising star. Since 1.0 in 2024 it has shipped minor versions quickly, and version 1.16.0 dropped in April 2026. GitHub stars passed 21,000. Gleam differentiates on exactly two axes. First, a type-safe BEAM language. Where Erlang/Elixir are dynamic with Dialyzer as a reinforcement, Gleam is statically typed from day one. Second, simplicity. Small grammar, no macros, the manual fits in one book. Elm's "simplicity first" philosophy ported into the BEAM family.

In 2026 teams starting a new BEAM service seriously consider Gleam. Hiring pool is small and libraries are still thinner than Elixir's. FFI to Erlang/Elixir is clean, so a common pattern is "Gleam for domain model, Elixir for infrastructure".

When is the BEAM family rational. First, messaging, real-time, multiplayer backends. Second, distributed systems where you want fault tolerance enforced in code. Third, LiveView for full-stack simplification. Irrational when the workload is CPU-bound (Rust or Go fits better), or single-node CRUD (vanilla Rails/Django ships faster).

6. The Lisp family — Clojure for enterprise, Racket for teaching, CL as living museum

The Lisp family is the original functional family. In 2026 it is best viewed through one anchor.

Clojure carries Lisp into industry. Clojure 1.12.5 shipped in May 2026, and the Clojure Documentary opened to the public in March that year. A 90-minute film featuring Rich Hickey, Alex Miller and Stuart Halloway. The fact that this documentary even exists is a signal — "Clojure is the language closing one chapter and opening the next." Nubank, which acquired Cognitect in 2020, continues to steward Clojure's development. Nubank runs its own core systems on Clojure and Datomic.

If you must pick one Clojure killer feature it is the persistent data structure. Immutable vectors, maps and sets that mutate in O(log32 n) time, with STM and atoms layered on top. That combination is what modernized Lisp into "concurrency plus data-first thinking". Enterprise data pipelines, fintech cores, event-driven microservices still favor it.

ClojureScript lives, but most new front-end projects are not picking it. shadow-cljs is solid tooling, re-frame is the canonical state manager, but TypeScript moved fast enough that ClojureScript's pitch has narrowed.

Racket anchors education and DSL research. How to Design Programs is the standard text, and Racket's macro system is among the most powerful around. Industry hiring is near zero.

Common Lisp is a living museum. SBCL is still fast, ASDF/Quicklisp work, some companies (graphics, garden automation, a few aerospace legacy systems) still run CL cores. Picking CL for a new project rarely has a sound rationale.

When is the Lisp family rational. First, data pipelines, JVM ecosystem, and functional thinking all in one (Clojure). Second, when DSLs are central. Irrational when the team is small and the desire for static analysis is high. There, Gleam or OCaml fits better.

7. The new line — Roc, Unison, Lean 4, Koka and their different bets

The new line has almost no industrial hiring, but it is where the most interesting experiments live. Four languages, four very different bets.

Roc is Elm's successor. The author is Richard Feldman, the one who wrote Elm in Action. As of May 2026 Roc is still pre-1.0. The last tagged release is alpha4 (August 2024) and Feldman said on The Changelog episode 645 that the goal is 0.1.0 sometime in 2026. The immediate target was making the new compiler usable for Advent of Code 2025, and a handful of people already experiment with it on side projects.

Roc has two distinguishing properties. First, platform-application separation. A Roc program can only call effects provided by a "platform" (web server, CLI, AWS Lambda). What side effects are possible is decided at the platform layer, not by the program. Second, fast compile plus fast runtime. Roc uses a morphic solver (an advanced form of static dispatch plus monomorphization) to deliver functional speed on both the compile and runtime axes. NoRedInk has funded a lot of this work.

Roc is not production-ready in 2026. But for anyone who loved Elm and dreams of "front end, server, and CLI all in one functional language" Roc is the most credible candidate.

Unison released 1.0 in November 2025. Its differentiator is content-addressable code. A function's identity is the hash of its abstract syntax tree, not its name. The same function carries the same hash, and once compiled the result is cached across the entire codebase. So "a strongly typed language with near-zero build times" becomes possible. Unison was designed from day one with a distributed runtime in mind (Unison Cloud) — sending a function to another machine for execution is a single line of code.

Unison's ability system is one of the cleanest industrializations of algebraic effects so far. A function type declares which abilities it needs, and handlers interpret abilities at the call site. What Haskell effects libraries chased is captured one level higher in the language itself.

Unison 1.0 shipped, but industry adoption is small. Its main users are Unison Cloud beta customers, with experimental adoption in data pipelines and serverless workloads. Hiring is near zero.

Lean 4 is the most rapidly transforming member of the new line. It started inside Microsoft Research, then in 2024 Leonardo de Moura moved to Amazon, and Lean FRO (Functional Reservation Organization) is now an independent nonprofit. Lean 4's identity covers two things at once. First, a theorem prover. Mathematicians use it to formalize results like the sphere-packing proof in 24 dimensions. Second, a systems language. Lean 4 is bootstrapped (itself written in Lean 4) and introduces "functional but in-place" — looking immutable but mutating in place by reference counting.

In March 2026 Mistral released Leanstral, an open-source AI agent for Lean 4. It is the first practical instance of an AI tool that proves code correctness with formal proofs. Industrial use of Lean 4 is still near zero, but it has become an important anchor for the bigger story of "formal verification in the AI era".

Koka is the language Daan Leijen leads at Microsoft Research. Version 3.0 shipped in January 2024 and minor releases land roughly monthly. Its distinguishing trait is row-polymorphic effect types. A function's type carries the row of effects it may produce. Effect handlers define async, exceptions, probabilistic programming as user libraries. It also features FBIP (functional but in-place) and a reference-counted memory model.

Koka's industrial use is near zero. But it is a key channel through which algebraic effects flow into other languages. OCaml 5's effect handlers were influenced by Koka, and Unison's ability system is a philosophical cousin.

When is the new line rational. Honestly, for production in 2026 it is irrational. Learning, side projects, R&D experiments, and absorbing the ideas of the next standard early — those are the rational scopes. Teams under a six-month delivery clock should not bet on the new line.

8. Functional but pragmatic — what the Effect-TS / fp-ts merger means

One of the biggest events in late 2025 was Giulio Canti's fp-ts joining the Effect-TS organization. Effect-TS now effectively occupies the fp-ts v3 slot, and future fp-ts work continues inside Effect. Effect-TS calls itself "the Haskell of TypeScript" but it is closer to ZIO (Scala) or Cats Effect for the TypeScript audience.

Effect-TS carries one large meaning. It does not ask you to leave the mainstream ecosystem and join the functional family. It brings functional tools into the mainstream language as a library. TypeScript is mainstream, React is the standard, Node and Bun run the infrastructure. On top of that, Effect, Schema, Layer, Context, Fiber let you "borrow the ideas of the functional family while not narrowing your hiring market".

Similar flows show up in other languages. Rust's thiserror + anyhow + tokio is essentially Result/Either plus structured concurrency for production. Swift's async/await + Result + actor is the same family of ideas. Kotlin has Arrow. Java has vavr and JEPs like 466 stream gatherers folding functional patterns into the mainstream. Scala has Cats Effect and ZIO as native citizens.

The conclusion is clear. You can capture 90 percent of functional thinking without picking a functional family language. For many teams adopting TypeScript with Effect is more rational than adopting Haskell and narrowing the hiring pool. The caveat is real: Effect-TS has a steep learning curve. The surface area is larger than fp-ts ever was. It is not a default for every team.

When is the functional-but-pragmatic route rational. First, when you want the philosophy but cannot afford to narrow hiring. Second, when you have an existing TypeScript/Rust/Swift codebase and want to add functional patterns incrementally. Third, when you accept that real systems are "half imperative, half functional". Irrational when you try to recreate "all of Haskell" inside TypeScript. That path delivers a heavy learning bill and little else.

8.5. The same task in five families — one page of code

Words abstract too much. Here is the same task expressed by five families on one page. The task is fixed. Receive a user id, look up the balance, return a typed error if absent. The simplest business logic, but it brings out each family's philosophy clearly.

OCaml. Explicit module, Result type, pattern matching.

module Balance = struct
  type error = NotFound | Frozen
  type t = { user_id : string; amount : int }

  let find_balance db id : (t, error) result =
    match Db.get db id with
    | None -> Error NotFound
    | Some r when r.frozen -> Error Frozen
    | Some r -> Ok { user_id = id; amount = r.amount }
end

Haskell. Monad transformers or an effects library (here, effectful).

findBalance :: (Reader Db :> es, Error AppError :> es) => UserId -> Eff es Balance
findBalance uid = do
  db <- ask
  row <- liftIO (Db.get db uid)
  case row of
    Nothing -> throwError NotFound
    Just r | rowFrozen r -> throwError Frozen
    Just r -> pure (Balance uid (rowAmount r))

Elixir. with construct, pattern matching, message passing inside GenServer.

def find_balance(db, uid) do
  with {:ok, row} <- Db.get(db, uid),
       false <- row.frozen do
    {:ok, %Balance{user_id: uid, amount: row.amount}}
  else
    :error -> {:error, :not_found}
    true -> {:error, :frozen}
  end
end

Gleam. Exhaustive matching enforced by the compiler, Result is the default.

pub fn find_balance(db: Db, uid: String) -> Result(Balance, Error) {
  case db.get(db, uid) {
    Error(_) -> Error(NotFound)
    Ok(row) if row.frozen -> Error(Frozen)
    Ok(row) -> Ok(Balance(user_id: uid, amount: row.amount))
  }
}

Clojure. Dynamic plus spec, branching by multimethod or cond.

(defn find-balance [db uid]
  (let [row (db/get db uid)]
    (cond
      (nil? row) [:error :not-found]
      (:frozen? row) [:error :frozen]
      :else [:ok {:user-id uid :amount (:amount row)}])))

Five families write the same task five different ways. None is strictly superior, but each family's emphasis is unambiguous. OCaml draws boundaries with modules. Haskell carves every side effect into the type. Elixir flattens the happy path with with. Gleam forces every branch through the compiler. Clojure stays dynamic and data-first.

8.6. Scorecard — hiring, tooling, ecosystem per family

What matters in industrial decisions is rarely philosophy. It is hiring, tooling, ecosystem. Looking through that lens makes the gap between families visible. Here is a subjective scorecard as of May 2026, out of 5.

Treat this as a snapshot, not an oracle. The hiring pool axis is the relative size of LinkedIn results in the English market. Tooling is the maturity of LSP, debuggers, and formatters. Libraries is the depth of standard work (HTTP, DB, JSON, auth). Learning material is the quality of books and official docs. Conferences/community uses activity frequency across 2025-2026.

A higher overall score does not mean a family is superior. A small hiring pool that perfectly matches your team can still be rational. Gleam's pool is small but coherent. Haskell's pool is small but Mercury proved ordinary developers can learn it.

9. Is picking a functional language for a 2026 startup rational

Let us answer this honestly. The answer is "rational for some families, irrational for others". You must split the question by family for it to mean anything.

Rational case 1 — Elixir + Phoenix LiveView for full-stack simplification. A team of one to three building an MVP fast, where real-time matters and distribution reliability matters from day one. LiveView is close to an unfair advantage. The hiring pool is small but overlaps with Rails developers. Fly.io, Felt, Cars Commerce, Brex actually run this pattern.

Rational case 2 — Haskell for fintech cores. Complex business rules, invariants enforced by types, small teams maintaining big codebases. Mercury is the canonical example. Hiring is hard, but their proof that "ordinary developers learn Haskell on the job" is now backed by years of evidence.

Rational case 3 — OCaml for compilers and infrastructure tools. Parts of Tezos, parts of Coq, parts of Docker for Mac are written in OCaml. Fast single binary, strong types, functor-based modularity. A natural fit for infra tooling.

Rational case 4 — Gleam for new BEAM services. Teams who love Elixir's philosophy but need static types. Starting a new BEAM project in 2026 makes Gleam a serious option. Hiring is very small.

Irrational case 1 — Elm for new front end. 0.19 has been frozen since 2019, hiring is near zero, the library set is not growing. Maintenance is fine, new is not. Until Roc reaches 1.0, React with Effect-TS is more rational.

Irrational case 2 — Roc, Unison, Lean 4, Koka for production. All beautiful, all risky in 2026. Teams with six-month delivery clocks should stay away.

Irrational case 3 — PureScript or Idris2 for full-stack. PureScript has React competing for the same mind share. Idris2 has zero hiring. Both are fine for learning, not for production.

Irrational case 4 — Common Lisp for a new SaaS. Unless your team is one genius engineer, do not recommend it.

One-sentence conclusion. "By family the functional camp is still a rational choice. There is no single answer that fits every family."

9.5. A short hiring guide per family — can you fill the team in six months

The biggest risk in a startup's first six months is people. So family choice ties directly to whether you can hire. Honest guide per family.

• Elixir — The pool of Ruby developers plus ElixirSchool/Pragmatic graduates is thick enough. A three-to-five-person full-stack team in six months is realistic. Seniors are scarcer.
• Haskell — Mercury's pattern is the correct answer. Not "only Haskell veterans" but "ordinary developers willing to learn plus one or two seniors". Plan for six to nine months to find seniors.
• OCaml — Senior hiring is genuinely hard. Outside the Jane Street, Tezos, and Coq circles the market is thin. Growing OCaml beginners into senior roles in-house is more realistic than poaching.
• F# — Internal migration from C# is the easiest path. External hiring is narrow but the cost of moving a C# developer into F# is low.
• Clojure — Nubank's gravity has grown Latin American (especially Brazilian) communities. The US market is narrow but stable.
• Gleam — The pool is essentially "BEAM developers willing to learn Gleam". Hire Elixir developers and add Gleam through onboarding.
• Erlang — Hiring is very narrow but poaching from a core telecom company is possible. That kind of experience is expensive.
• ReScript — Outside a handful of Japanese and US shops there is almost no hiring. Internal training is essentially the only path.
• Roc/Unison/Lean 4/Koka — Hiring is zero. The only path is growing a beginner into a senior over a year or more.

The point of the guide is simple. "Hire only veterans" fails in almost every functional family. Mercury said it explicitly, and the other functional production shops repeat the same pattern in practice. Ordinary developers willing to learn, plus a small number of seniors, plus a real internal training program. That combination is the only realistic way to staff a team within six months.

9.6. Functional ideas already leaked into the mainstream

One last big perspective. One truth in 2026 is that "you do not need to pick a functional language because functional already mostly won". The mainstream languages have absorbed almost the entire idea set.

• Rust — Result, Option, ownership, pattern matching, the match expression, the question-mark operator, lifetime tracking. All sourced from the ML and Haskell families.
• Swift — Optional, Result, async/await, actor, Sendable, if-let. Apple's absorption of ML ideas.
• Kotlin — Result, sealed class, the when expression, scope functions, Flow. Scala and Haskell influence runs deep.
• TypeScript — Union types, narrowing, discriminated unions, satisfies, as const, template literal types. Haskell-family ideas absorbed gradually.
• Java — Optional, sealed class, switch expression, pattern matching, record. Even the most conservative language has absorbed the fusion of functional and OOP.
• C# — record, pattern matching, Nullable, async/await. F# influence flows directly.
• Python — typing.Protocol, the match statement, dataclasses. Slow but absorbing.

What does this trend mean. First, you can capture 90 percent of functional thinking without picking a functional language. Effect-TS is a "let's grab the last 10 percent" attempt in TypeScript. Second, the real value of a functional family is not the ideas themselves but the environment that enforces them. Haskell's real value is not monads but "the compiler that refuses to let function signatures lie". Elixir's real value is not the actor model but "OTP enforcing fault tolerance in code".

With that perspective, family choice becomes simple. Just the ideas, pick mainstream plus Effect/Arrow/Cats. Need enforcement, pick a functional family.

10. If you had to pick one — killer feature per family in one line

Closing with a one-line killer feature per family. Hiring, libraries, and tools shift over time, but "the biggest gift this family can give other families" rarely shifts.

• OCaml — module system and functors. The best tool for abstracting a large codebase.
• F# — functional domain modeling on top of .NET. The natural ramp from C#.
• Haskell — tracking effects in the type. Refactors stop being scary.
• Elm — "simplicity equals reliability". The cleanest expression of that thesis even if the language is frozen.
• PureScript — Haskell on JS, taken seriously. Narrow but deep.
• Idris2 — types as specifications. Not industrialized, but the idea flowed elsewhere.
• Erlang / OTP — Supervisor trees. The standard pattern for distributed fault tolerance.
• Elixir — LiveView plus OTP. A small team's full-stack unfair advantage.
• Gleam — small grammar on BEAM. "Simplicity first" reborn on the family.
• Clojure — persistent data structures and the REPL. Canonical data-first thinking.
• Racket — macros and DSL design. The teaching and research anchor.
• Common Lisp — runtime mutation. Living museum that still teaches.
• Roc — platform and application separation. The platform decides what effects are possible.
• Unison — content-addressable code. Functions identified by hash, not name.
• Lean 4 — dependent types plus AI. Anchor for industrial code verification.
• Koka — row-polymorphic effects. Effects gathered as a row inside the type.
• Effect-TS — functional power without joining a functional family.

Epilogue — A checklist for the next decision

To close the survey, here is a checklist and a list of anti-patterns for the next time you have to choose.

Pick-time checklist

• Domain is distributed, real-time, messaging → consider the BEAM family first
• Domain is complex business rules (fintech, insurance, accounting) → Haskell, OCaml, F# candidates
• Domain is compilers, static analyzers, infra tooling → OCaml, Haskell candidates
• Domain is data pipelines plus JVM ecosystem → Clojure candidate
• Domain is full stack with one to three engineers → Elixir + Phoenix LiveView first
• Domain is a new BEAM service → compare Gleam vs Elixir
• Domain is learning, R&D → Roc, Unison, Lean 4, Koka are fair game
• Domain is plain CRUD → you do not need a functional-family language. TypeScript + Effect or just mainstream

Anti-patterns

• "Haskell looks cool" — narrowed hiring plus learning curve plus thin libraries, all at once
• "Elm for a new front end" — irrational in 2026, wait for Roc 1.0 or go React
• "Lisp for a brand new SaaS" — risky unless the team is one genius
• "Adoption resting on one PhD" — if they leave, the team collapses
• "Functional family without checking hiring" — six months in you run out of people
• "Effect-TS without learning the philosophy" — steeper than fp-ts, do not skip the training
• "Roc, Unison, Lean 4 in production" — even after 1.0 the ecosystem is thin

Next post

The next post deep-dives the "functional but pragmatic" path. Topic: Effect-TS in practice for 2026 — a step-by-step adoption of Schema, Layer, Context and Fiber in a real project. It covers the migration path from fp-ts, runtime validation through Schema, clean dependency injection with Layer, and an honest take on how far "TypeScript plus Effect" actually scales in industry.

References

• Gleam programming language — official site
• Gleam Gathering 2026 reflections — Alembic
• Roc programming language — official site
• Richard Feldman on Roc — The Changelog Interviews 645
• Unison — official site
• Unison: A friendly programming language from the future — GitHub
• Jane Street and Docker on moving to OCaml 5 at ICFP/SPLASH 2025 — Anil Madhavapeddy
• Introducing OxCaml — Jane Street Blog
• Oxidizing OCaml: Rust-Style Ownership — Jane Street Blog
• Technology at Jane Street
• A Couple Million Lines of Haskell: Production Engineering at Mercury — blog.haskell.org
• Haskell in Production: Mercury — Serokell
• Haskell in Production: Standard Chartered — Serokell
• Haskell ecosystem activities report: Q1 2026 — Well-Typed
• Elm Software Foundation — Elmcraft
• Elm language — Wikipedia
• Lamdera — Full-stack Elm
• PureScript Halogen — GitHub
• Idris 2 — official site
• The Koka Programming Language
• Daan Leijen at Microsoft Research
• Koka project — Microsoft Research
• Lean 4 — official site
• The Lean 4 Theorem Prover and Programming Language — Microsoft Research
• Clojure documentary trailer — clojure.org
• Clojure 1.12.5 release notes
• Introducing F# 10 — .NET Blog
• What's new in F# 10 — Microsoft Learn
• F# 10 Brings Performance Improvements — InfoQ
• Effect-TS vs fp-ts — Effect Documentation
• fp-ts joins Effect-TS — GitHub
• Why We Love Functional Programming but Don't Use Effect-TS — Harbor
• Elixir set-theoretic types — José Valim blog
• Phoenix Framework — official site
• WhatsApp Engineering on Erlang — Code BEAM talks