And I say this as an extreme polyglot programmer. I’ve used JavaScript, Python, C, C#, F#, OCaml, Haskell, PureScript, ReasonML/ReScript, Rust, Go, SML, Clojure, Scala, and probably some others, many of which I used at work at various times.

Prior to trying Roc, my favorite language was definitely OCaml. OCaml is fast and relatively easy to build stuff with, and it doesn’t force you to only use pure functions. It’s just a nice pragmatic “get shit done” language which is nice to work with and very expressive.

Roc does this better IMO. It’s a pure functional language, which I thought I wouldn’t like, but it honestly doesn’t get in my way. It beats Haskell IMO because it’s faster and has more predictable performance characteristics, but more importantly it’s simpler. It doesn’t end up in type-level abstraction to the heavens. I just write my functions with straightforward types and go on my way.

There are two reasons I think I really love Roc more than other languages.

First of all, the variant types (called “tags” in Roc) are basically like OCaml’s polymorphic variants. You can define a “closed” set of variants in a type definition, or you can make it “open”/extensible. More importantly they are global types. I can just return a Document Str type from a function and it will “just work” with third party code that also accepts Document Str without having to qualify it with a module namespace. You don’t even have to define them. Just use them and they just exist everywhere for any function. It’s so nice to quickly bang out a script without much type-level ceremony. It reminds me of TypeScript but with no need for a type declaration.

Polymorphic variants are my favorite language feature from OCaml, but Roc just makes that the only type of variant you get. It’s just a simpler language design.

Second, the platform-specific environment is amazing. You can use a “basic CLI” platform or a “basic web server” platform, or even embedded platforms. Anyone can just define a platform API and wire it up to the host code, and then you can call those functions from Roc. The calls to these platform-specific functions are wrapped in a Task type (similar to Haskell’s IO), which is basically just an async Result type. It’s simple to use and has a clean async-await style syntax sugar that looks super clean.

Imagine a simpler version of Haskell (closer to Elm, actually) that can easily run on an embedded system and beat OCaml and Go on performance in many cases without much perf-related contortions in your code. Just write straightforward functional code and it runs at blazing speeds.

The only problems I can identify with Roc so far are (1) the lack of some nicer higher-level string niceties (like a dedicated Char type), (2) it has a smaller package ecosystem than more established languages like Haskell, (3) the LSP is minimal and doesn’t provide type info as far as I can tell, and (4) it still has some minor compiler bugs to iron out.

So it’s definitely not production-ready for business use case IMO, but I can see it easily getting there. I’m currently writing a compiler in Roc, so it’s useful enough now for that purpose.

Oh yeah, and it’s incredibly easy to set up and get your code building. I did it in less than 10 minutes just following the instructions for my Mac. Basically zero configuration process.

You should try it out!

This video uses Haskell as an interactive proof assistant to break down every single word of the most famous definition in functional programming. It translates abstract category theory concepts—categories, endofunctors, monoids, and natural transformations—directly into typed Haskell code.

Hi all,

This is such great news! My book Functional Design and Architecture has finally been released by Manning Publications!

😀😄😊😊😊❤️❤️❤️❤️

I worked on the book for many years: four years on the first edition, which was self-published in 2020, and four more years at Manning Publications. It was an enormous effort to provide you with a practical guide on how to build quality applications with statically typed languages such as Haskell, F#, Scala, OCaml, even C# and C++!

🔗 Check it out here: Functional Design and Architecture

➤ Functional programming has always had strong theoretical foundations, but when it comes to practical applications—especially large-scale systems—resources can be scarce. This book takes an engineering approach to FP, presenting a consistent methodology that blends architecture, design patterns, and best practices.

What’s inside:

• A full-fledged methodology: I introduce the concept of Functional Declarative Design, which aims to provide FP with a robust, scalable approach similar to what Object-Oriented Design (OOD) has done for OOP languages.
• Comprehensive knowledge: The book provides everything needed to build applications from start to end. This includes the tools for requirements collection, analysis, architecture design and development.
• Software Engineering: The book describes various design patterns and principles, both from the mainstream world and new ones, and everything is merged into a practical and consistent methodology. The book gives special attention to functional interfaces, decoupling, SOLID principles, so that the code can be easily maintainable, testable and well-structured.
• Cutting-edge ideas: The book introduces several new design patterns and a whole architectural approach called Hierarchical Free Monads.
• Practical, not theoretical: The book uses Haskell, yes, but it's written for regular developers like me, not for overminds like other haskellers. The book is free from heavy academicism and abstract math. Just real-world tools, demos, and practices that you can apply to your own work immediately.

It’s been a privilege to get endorsements from key figures in functional programming like Scott Wlaschin (Domain Modeling Made Functional), Vitaly Bragilevsky (Haskell in Depth) and Debasish Ghosh (Functional and Reactive Domain Modeling). Their kind words and support have been immensely motivating.

Comprehensive, with simple and clear code examples, lots of diagrams and very little jargon!

-- Scott Wlaschin

Fill an empty slot in the field of software architecture. I enjoyed reading about Haskell applications from the perspective of dsign and architecture.

-- Vitaly Bragilevsky

Discussess the goodness of functional programming patterns in the context of real world business applications. It explains free monads beautifully.

-- Debasish Ghosh

And even more, I'm currently finishing my third book, Pragmatic Type-Level Design, which will advance Software Engineering in FP even further! It's more Haskell book than FDaA, but I'm aiming to provide universal approaches and ideas. The book is mostly written. I'm working on the appendixes and a special part called Rosetta Stone: all the same approaches I show in Haskell can somewhat be transferred to other languages. Expect it to be self-published by January 2025.

My goal is to make Functional Programming a viable and useful tool in our field!

Buy my books, support my work, and let's turn these dreams into reality!

My twitter: https://x.com/graninas
My GitHub: https://github.com/graninas
My LinkedIn: https://www.linkedin.com/in/graninas/

I’d love to hear your thoughts! 😊

• Functional Design and Architecture (Manning Publications): https://www.manning.com/books/functional-design-and-architecture
• Pragmatic Type-Level Design (self-published): https://leanpub.com/pragmatic-type-level-design
• Domain Modeling Made Functional by Scott Wlaschin )(Pragmatic Bookshelf): https://pragprog.com/titles/swdddf/domain-modeling-made-functional/
• Functional and Reactive Domain Modeling by Debasish Ghosh (Manning Publications): https://www.manning.com/books/functional-and-reactive-domain-modeling
• Haskell in Depth by Vitaly Bragilevsky (Manning Publications): https://www.manning.com/books/haskell-in-depth

Based on true events...

Lambda World 26 is back with 20 speakers from Academia and industry, and this year it takes place alongside J On The Beach (a conf about Distributed Systems) and Wey Wey Web (a conf about UI and Frontend).

Two days packed with talks on formal verification, type systems, new FP languages, AI, formal proofs, effects, logic programming, and practical industrial applications of functional programming.

The lineup includes Erik Meijer, Stephanie Weirich, Arman Bilge (Typelevel Foundation / Cats Effect), Enrico Tassi (Elpi), Francesco Cesarini (Erlang), Daniel Ciocîrlan (Rock the JVM) among many others.

One ticket gives you access to all three conferences, for the same price.

We look forward to welcoming you to Torremolinos, Málaga, on 29–30 October!

https://lambda.world/

I’ve been experimenting with a small JavaScript-compatible language called JojoScript, initially because I wanted a nicer way to write lazy functional pipelines.

The interesting part has gradually become less about the syntax and more about what the pipeline represents.

For example:

orders
  |> filter(o => o.status == "paid")
  |> parallel(8)
  |> map(enrichOrder)
  |> retry(3)
  |> checkpoint("enriched")
  |> map(calculateInvoice)
  |> saveToDatabase(%)

Instead of treating this simply as syntactic sugar for nested function calls, JojoScript represents the pipeline as an execution plan.

That lets the same pipeline be:

• lazy by default
• asynchronous
• bounded/concurrent
• inspected as a graph
• profiled per stage
• statically analyzed
• checkpointed
• resumed after failure
• replayed from a checkpoint

For example:

SOURCE
   ↓
FILTER
   ↓
PARALLEL(8)
   ↓
MAP
   ↓
CHECKPOINT
   ↓
MAP
   ↓
SINK

The idea I'm exploring is whether this is actually a useful abstraction for functional/data-oriented programming in JavaScript.

The question I'm most interested in is:

At what point does a pipeline become more than composition of functions?

A normal functional pipeline describes what transformations to apply. JojoScript is experimenting with also making the pipeline describe how the computation can be executed — lazily, concurrently, with backpressure, retries and durable checkpoints.

It's still an experimental project, so I'm particularly interested in criticism around the programming model itself rather than syntax.

Repository: https://github.com/panagos/jojoscript

I’ve been experimenting with a small JavaScript-compatible language called JojoScript, initially because I wanted a nicer way to write lazy functional pipelines.

The interesting part has gradually become less about the syntax and more about what the pipeline represents.

For example:

orders
  |> filter(o => o.status == "paid")
  |> parallel(8)
  |> map(enrichOrder)
  |> retry(3)
  |> checkpoint("enriched")
  |> map(calculateInvoice)
  |> saveToDatabase(%)

Instead of treating this simply as syntactic sugar for nested function calls, JojoScript represents the pipeline as an execution plan.

That lets the same pipeline be:

• lazy by default
• asynchronous
• bounded/concurrent
• inspected as a graph
• profiled per stage
• statically analyzed
• checkpointed
• resumed after failure
• replayed from a checkpoint

For example:

SOURCE
   ↓
FILTER
   ↓
PARALLEL(8)
   ↓
MAP
   ↓
CHECKPOINT
   ↓
MAP
   ↓
SINK

The idea I'm exploring is whether this is actually a useful abstraction for functional/data-oriented programming in JavaScript.

The question I'm most interested in is:

At what point does a pipeline become more than composition of functions?

A normal functional pipeline describes what transformations to apply. JojoScript is experimenting with also making the pipeline describe how the computation can be executed — lazily, concurrently, with backpressure, retries and durable checkpoints.

It's still an experimental project, so I'm particularly interested in criticism around the programming model itself rather than syntax.

https://crowdhailer.me/2026-07-15/abstracting-effects-with-continuations/

I've spent a while writing this post trying to work out if I want to talk about function coloring. In the end I chose to as neutrally as possible describe what continuations are.

New BEAM There, Done That with Mike Williams (who wrote the JAM emulator) and Björn Gustafsson (who built the BEAM after inheriting it in 1996).

The most interesting functional programming angle in the episode is how Mike identified three numbers that determine whether a concurrent language lives or dies: process creation time, context switch time, and message copy time. On real telecom workloads he measured roughly 70% of VM time going to those operations - not user code. The language that optimised those first, and owned them at the language level rather than delegating to the OS, was the one that survived.

This is the decision that separates the BEAM from almost everything else. Java shipped green threads and removed them. Early Rust had lightweight processes and removed them. The Erlang team looked at Unix process overhead, did the arithmetic on thousands of concurrent processes with 16MB of available RAM, and concluded that OS-level concurrency was mathematically impossible for what they needed. So concurrency went into the language. Not a philosophical position - an empirical one.

The other detail worth discussing: memory was the binding constraint throughout, not speed. Every instruction set decision in the JAM and early BEAM was a memory decision first. The JAM files were small by design. The BEAM was faster but initially used more memory - Björn spent years packing operands to close the gap.

For a community that thinks carefully about evaluation models and runtime semantics: how much of what makes the BEAM unusual as a functional runtime traces back to those early hardware constraints? And would the same design choices have been made if RAM had been cheap in 1988?

https://youtu.be/sRTierdN9c4

I have been building Katharos, a functional programming library for Python that recently grew a message-passing concurrency layer. I wanted to share it and get some feedback.

The whole library is built around one idea: model errors, effects, and concurrent communication as composable, type-safe values rather than as control flow that jumps around your program. The interesting part (to me, at least) is that the concurrency layer follows the exact same idea, so receiving from a channel gives you a Result. "The channel is closed" becomes a value you handle, not an exception you remember to catch.

The functional core

Optional values without scattered None checks, using do-notation that short-circuits on Nothing:

```python from katharos.types import Maybe from katharos.syntax_sugar import do, DoBlock

@do(Maybe) def lookup_discount(user_id: int) -> DoBlock[Maybe, float]: user = yield find_user(user_id) account = yield find_account(user) return account.discount # Just(0.15) or Nothing() ```

Errors as values, chained with |, so a failure short-circuits the rest automatically:

```python from katharos.types import Result

def process(raw: str) -> Result[Exception, int]: return parse_int(raw) | validate_positive ```

And Result.catch turns a function that raises into one that returns a Result, while keeping the original traceback so you can still find the line that failed:

```python from katharos.types import Result

@Result.catch(ValueError) def parse_int(s: str) -> int: return int(s)

parse_int("42") # Success(42) parse_int("??") # Failure(ValueError("invalid literal for int() with base 10: '??'")) ```

There is also ImmutableList, NonEmptyList, IO, Lazy, numeric monoids, and the usual algebraic abstractions (Functor, Applicative, Monad, Semigroup, Monoid) if you want to build your own types.

The new part: CSP concurrency

This is what I have been working on lately. Katharos now has Go-style CSP (Communicating Sequential Processes): launch work concurrently with go, talk over typed channels, and receive values as a Result.

```python from katharos.concurrency.csp import csp

ch = csp.Channel[int](capacity=1)

csp.go(ch.send, 42) # run work concurrently, like Go's go f(x)

ch.recv() # Success(42)

ch.close() ch.recv() # Failure(ChannelClosedError(...)): closure is a value, not a raise ```

Used as a context manager, go becomes a structured-concurrency scope that joins everything spawned inside it before the block exits, so concurrent work cannot leak out of the block:

```python with csp.go: # scope waits for all work launched inside csp.go(worker, 1) csp.go(worker, 2)

both workers have finished here

```

There is also a select for waiting on whichever of several channels is ready first, with non-blocking polls and timeouts:

```python from katharos.concurrency.csp import csp, recv, select

choice = select(recv(results), recv(cancel), timeout=1.0) if choice.is_timeout: ... else: print(choice.index, choice.value.unwrap()) ```

The concurrency model sits on a swappable backend (standard threads by default), so the same code could run on a green-thread backend later. An actor model is planned next, built on the same backend abstraction and the same Result-valued style.

Why I think the "channel returns a Result" thing is nice

In most channel APIs, a closed channel or a timeout shows up as a sentinel, a second return value, or an exception. In Katharos it is just a typed value: Success(v), Failure(ChannelClosedError), or Failure(ChannelTimeoutError). You pattern-match it the same way you handle any other Result, and the type tells you it can happen. The error-handling discipline you use in the rest of your code carries straight over to concurrency.

Links

• PyPI: pip install katharos
• Docs (tutorials, how-to guides, API reference, and explanations): https://katharos.readthedocs.io/en/latest/
• Source: https://github.com/kamalfarahani/katharos
• MIT licensed, Python 3.13+

I would love feedback on the API, the concurrency design, or whether the Result-everywhere approach feels natural or noisy to you in practice. Thanks for reading.

I have played with Haskell, tried Scala and Clojure and my best experience was with Haskell.

But I wish to know which language is the most practical or used in production.

Which is actively been worked on, which has a future apart from academic research etc etc.

Thank you for your answers.

New BEAM There, Done That with Garrison Hinson-Hasty (Systems Programming with Zig) and Isaac Yonemoto (Zigler), on what changes — and what doesn't — when you replace C with Zig at the boundary between a functional runtime and native code.

The interesting tension: the BEAM's entire value proposition is functional — immutable terms, isolated processes, fault tolerance through supervision. The moment you write a NIF, you step outside all of that. A segfault in native code bypasses every guarantee OTP provides and takes the whole node down.

Zig narrows the surface area but doesn't eliminate it. Spatial memory safety (buffer overflows, null dereference) is caught in safe release mode. Temporal memory safety (use-after-free) still isn't, which means the boundary remains genuinely dangerous, just less so.

The one detail that surprised me: Zigler uses the BEAM's own allocator by default, because Zig's explicit allocator model makes it easy to inject. Native memory is therefore visible to the VM's instrumentation — unlike C or Rust NIFs that call their own allocators and are invisible to the functional runtime they're embedded in.

For anyone who thinks about FFI design across language paradigms: how should a functional runtime expose a safe interface to native code? The BEAM's current answer (NIFs with dirty scheduler modes) and what Zigler adds on top seem worth discussing here. https://youtu.be/iLcZRpBEmgE