FUNARCH 2026 – Preliminary Table of Contents

4th ACM SIGPLAN International Workshop on Functional Software Architecture (FUNARCH 2026)

Frontmatter

Keynote

Functional Mechanical Sympathy (Keynote)
Richard Feldman
(Zed Industries, USA)
For the first time in decades, the two fastest-growing mainstream programming languages are not object-oriented. They are statically typed, with first-class lambdas, and are known for their concurrency stories. They are Go and Rust, both imperative.
If object orientation is no longer a requirement for mainstream adoption, and lambdas have become commonplace, why aren't two functional languages the fastest-growing? One selling point that makes Go and Rust stand out is performance. Go offers solid runtime performance and garbage collection, while Rust offers substantially more performance, but at the cost of substantially higher language complexity and build times.
Their growing popularity can't be explained by paradigm familiarity alone. The most popular modern JavaScript build tools are written in Go and Rust, often by programmers who enthusiastically practiced a functional style in their TypeScript code bases before learning Go or Rust specifically in order to get the performance they needed. Even though they liked FP, they couldn't find a way to achieve their performance goals with it.
In many cases, the performance of functional programs comes down to architecture. Some architectures are better-suited than others to patterns of processor and memory usage that run fast on modern hardware. In any domain where performance is more than a nice-to-have, the correctness and comprehensibility benefits of a functional architecture will be weighed against the runtime performance of the programs it produces.
This talk will dive into the intersection of functional programming and mechanical sympathy: how we can achieve faster-performing functional programs by architecting with the machine in mind.

Publisher's Version Article: icfpws26funarchmain-key1-p doi:10.1145/3830438.3839102

Papers

From Lambda to Ledger: An Architectural Comparison of Plinth and Plutarch
Seungheon Oh, Ziyang Liu, and Philip Wadler
(Input Output, USA; University of Edinburgh, UK; Input Output, UK)
Plinth and Plutarch are two languages for writing smart contracts on the Cardano blockchain. Both are based on Haskell, have been used in production over the past few years, and share the same host ecosystem and compilation target. However, they have strikingly different architectures: Plinth compiles a subset of Haskell through deep integration with GHC, while Plutarch represents its programs as explicitly constructed typed terms embedded within Haskell. These choices lead to different balances between abstraction and performance, reuse and specialization, and user experience and implementation effort.
This paper presents an architectural comparison of these two approaches, grounded in the authors' experience implementing and using both languages. We analyze their design trade-offs across multiple dimensions, and present an empirical evaluation on representative programs, examining how architectural choices affect source code, generated target code, and compiler error messages. Our comparison offers broader insights for language design, both within and beyond the blockchain domain.

Publisher's Version Article: icfpws26funarchmain-p2-p doi:10.1145/3830438.3830956

Local-First Distributed Configuration (Experience Report)
Michael Sperber
(Active Group, Germany)
We have been developing a distributed application called Lokalisierung using functional programming since 2015. Lokalisierung automatically configures mobiles devices in a large organization of car-inspection shops. It uses peer-to-peer synchronization to distribute configuration data among the devices, without the use of a central server. This paper describes the original design and evolution of the system. Specifically, we highlight how the event-based architecture supports synchronization but also enables flexibility for changes after the original rollout such as undoing configuration changes, and database thinning. We also reflect on design and implementation mistakes we made during its 10-year development.

Publisher's Version Article: icfpws26funarchmain-p5-p doi:10.1145/3830438.3830957

Functional State Machines in Rust: Typestate and Newtype Patterns (Experience Report)
Leon Heuer, Falk Woldmann Lu, and Jan Haase
(NORDAKADEMIE Hochschule der Wirtschaft, Germany; Otto, Germany)
We investigate the effects on code quality of the design patterns typestate and newtype in the language Rust, by conducting three case studies from production code, evaluated through expert interviews, static code analysis and benchmarks. The findings indicate that: (1) Typestate improves code faultlessness and testability, but comes at the cost of more boilerplate code and can degrade readability. Code with extensive branching logic and many invariants likely benefits most from the pattern. (2) Newtype combined with the "Parse, don't validate" principle improves code quality at a low cost and prevents invalid states at runtime.

Publisher's Version Article: icfpws26funarchmain-p6-p doi:10.1145/3830438.3830958

proc time: 0.01