“Functional Software Architecture” refers to methods of construction and structure of large and long-lived software projects that are implemented in functional languages and released to real users, typically in industry.
The goals for the workshop are:
To assemble a community interested in software architecture techniques and technologies specific to functional programming;
To identify, categorize, and document topics relevant to the field of functional software architecture;
To connect the functional programming community to the software architecture community to cross-pollinate between the two.
FUNARCH 2026 will be co-located with ICFP 2026 in Indianapolis, Indiana on August 29, 2026.
News is available on Mastodon, Bluesky, and Twitter.
The CFP is open.
The CFL is open.
TBD Are available from the ACM Digital Library.
FUNARCH adheres to the SIGPLAN/ICFP Code of Conduct.
This years videos will be available as a YouTube playlist; just like last year's.
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.
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 real-world 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.
We have been developing a distributed application called Lokalisierung using functional programming since 2015. Lokalisierung automatically configures mobiles devices in an 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.
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.
A continuation of my talk from last year. In this lightning talk I'll further speculate about how to make sense of Functional Architecture.
This talk is the yearly recap and retrospective of the FUNARCH workshop.
Unfortunately, this talk was not recorded.
Jeffrey Young (Canonical)
Nicolas Wu (Imperial College London)
Christiaan Baaij (QBayLogic)
Laurent P. René de Cotret (Bitnomial)
Facundo Dominguez (Tweag)
J. Garrett Morris (University of Iowa)
Ryan Scott (Galois)
Isabella Stilkerich (Schaeffler Technologies)
Katsuhiro Ueno (Niigata University)