Hi everyone,

Long time backend operator who has taken a path like this:

Bash -> python -> Go

I thought Procedural programming in Go would click, but it’s still just not resonating much. Though I have to say that single binary plus built in testing is super nice.

In python I do not do any classes or methods. I think in runbooks, pipelines, and dags with a very clear entry point and a clear exit point. Step 1 through 10. Inputs and outputs. Functions only.

Stuff like ORM, OOP, and MVC just don’t resonate with me at all. I know they have their place but like I’m all about top to bottom thinking. Example I love is SQL pipes or GoogleSQL where you start with a big set of data and each line below it filters it down. VS traditional SQL where it’s kinda jumping around all over the place. Or CTE where it’s very clear what each step is doing.

Doing some research I saw the syntax of Clojure and it really seemed intuitive RIGHT AWAY. Elixir also looked good but Clojure seemed much more bash like.

What problem am I trying to solve? I’ve been lucky to have opportunities to learn a lot of platforms, so I consider myself a plumber who needs to be able to connect anything anywhere, automate it, bring visibility, and operational excellence.

It can be anything backend from multi-cloud, services, API, on-prem, OS, DB, you name and I will connect it.

But, I am terrible at front end so there’s that lol

Has anyone been down this path and what’s the landscape look like for the backend in 2026?

Pyfun is a functional-first language for the Python ecosystem. You write algebraic data types, exhaustive matching, curried functions and pipes, and it compiles to plain Python that you can read, commit, and hand to someone who has never heard of Pyfun.

The compiler is written in Rust and everything is checked before any Python exists: types, exhaustiveness, effects, units.

Here is a whole program:

type Shape =
  | Circle float
  | Rect float float

let area s =
  match s:
    case Circle r: 3.14159 * r * r
    case Rect w h: w * h

[Circle 1.0, Rect 2.0 3.0]
|> List.map area
|> print

and here is the Python it compiles to, in full:

from dataclasses import dataclass

def _pf_map(f, xs):
    return list(map(f, xs))

@dataclass(frozen=True, repr=False)
class Circle:
    _0: float
    def __repr__(self):
        return f"Circle({self._0!r})"

@dataclass(frozen=True, repr=False)
class Rect:
    _0: float
    _1: float
    def __repr__(self):
        return f"Rect({self._0!r}, {self._1!r})"

def area(s):
    match s:
        case Circle(r):
            return 3.14159 * r * r
        case Rect(w, h):
            return w * h
        case _:
            raise RuntimeError("non-exhaustive match")

print(_pf_map(area, [Circle(1.0), Rect(2.0, 3.0)]))

A match comes out as a match. A variant comes out as a frozen dataclass. The pipeline comes out as an ordinary call. There is nothing to pip install alongside the output, and if you stop using Pyfun tomorrow you keep working Python.

Delete the Rect case and the compiler names what you missed:

error: non-exhaustive match: `Rect _ _` is not matched
 --> 6:3
  |
6 |   match s:
  |   ^^^^^^^^

Also in there:

• Hindley-Milner inference, so there are no type annotations on let at all.
• Inferred effects, so a function that prints or mutates gets io in its type and you can assert purity with let pure. Units of measure that reject metres + seconds and erase to plain numbers.
• Computation expressions for async, seq, and result, plus your own builders. Opaque types. A typed extern for calling any Python library you like.

Try it in the browser, nothing to install: https://simontreanor.github.io/Pyfun/playground/

22 lessons, written for people who know some Python: https://simontreanor.github.io/Pyfun/

Source, and the compiler internals tour: https://github.com/simontreanor/Pyfun

pip install pyfun-lang

I built this because most people meet programming through Python, and then to meet functional programming they have to pick up a second ecosystem to do it. I welcome all questions, bug reports, posts about things you have made, arguments about syntax, and anything else to help improve the language for everyone.

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.

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.

I wrote “sum . filter odd” with typescript’s type system.

It’s pretty simple as far as functional programming goes. Even at the type level one can easily achieve this in Idris or even Haskell. For this reason I was unsure of whether to share it here… Nevertheless it’s about functional programming and I figured I’d share it and let your feedback guide me on whether to share more of these here in the future.

Hello everyone. I am thinking of starting a tech business (startup) through software development and I'd like to use FP as the main selling point or uniqueness. I am like looking for suggestions on what languages to use or tech stack. From my first searches I got elixir. I also know haskell, so aside from haskell, what can you suggest. I'm also aware of using imp lang like C++ to make programs following an FP design paradigm.

Edit: I don't wish to argue on starting business or not (But I welcome them sure) . That is a different topic on its own. I'm just like more curious to see the state of the art in using FP tools.

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

Hi Everyone!
Me and my team are looking to expand our developer team and looking for programmers with some knowledge in the field of compilers, programming language design, and/or the Raku language! If you just like the idea of building a new programming language as well, please reach out!

I cannot disclose the exact nature of the language for the sake of project secrecy, but please DM me with your credentials and interests for details if you're interested.

Hi folks, this is Alexis' talk from SSW earlier this month. I thought you all would enjoy it!

Hi all,

I've been a software developer for about 10 years and I've been curious about FP for half of this time. Eventually, I picked up SML as my language of choice (OCaml is mostly some random line nose for me, and in Haskell/PureScript type classes are so pervasive, they make the language almost impenetrable for beginners).

So my goal has been to:

- lex the source code,
- parse it using parser combinators,
- (do some AST manipulations),
- evaluate it.

This is the repository where I keep my source code, and a README file. The gist of this file is:

- it's not Scheme,
- this is a WIP
- compiler: MLton + MLB basis files
- using SuccessorML as much as possible.

I try to keep the code clean, concerns separated as much as possible, meaningful signatures & structs, clear types).

ALL constructive criticism is very much welcome. I'm not an SML pro, so bear with me.

PS I posted it in r/sml too, but oh well - under a different username (logged in with my old Google acc), I'm not impersonating anyone (image the drama).

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

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.

One of the top five most popular and highly recommended programming katas over the past 20 years has been the Bowling Game Kata, in which TDD is used to write a program that computes the score of a Ten Pin Bowling Game.

In this deck we are going to explore how such a program may look when coded using different programming paradigms.

New BEAM There, Done That with Guillaume Dubois (Dashbit, PhD from IRIF Paris under Castagna) and Annette Bieniusa (RPTU Germany, building a parallel etalizer for Erlang) on what's shipping in Elixir 1.20 and why it took 30 years.

The FP angle: set-theoretic types - unions, intersections, negations - map naturally onto how BEAM pattern matching already works semantically. The gradual dynamic escape hatch is embedded into the type lattice structurally, not as a nominal exception. Message passing is still untyped for now.

The episode raises one question I'd put to this community: the BEAM's reliability model is supervision trees and let it crash, not static correctness. Both guests argue types and OTP solve different failure classes and aren't in tension. Does that framing hold, or does adding types change something fundamental about how you design for failure? https://youtu.be/X_CPDt3PeDE?si=j7Gneb1pFyFtgUGI