FUNARCH '26: "Functional State Machines ..."
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.
Article Search
Article: icfpws26funarchmain-p6-p doi:10.1145/3830438.3830958
FUNARCH '26: "Functional State Machines ..."
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.
Article Search
Article: icfpws26funarchmain-p6-p doi:10.1145/3830438.3830958
FUNARCH '26: "From Lambda to Ledger: An ..."
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.
Article Search
Article: icfpws26funarchmain-p2-p doi:10.1145/3830438.3830956
FUNARCH '26: "From Lambda to Ledger: An ..."
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.
Article Search
Article: icfpws26funarchmain-p2-p doi:10.1145/3830438.3830956
FUNARCH '26: "Local-First Distributed Configuration ..."
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.
Article Search
Article: icfpws26funarchmain-p5-p doi:10.1145/3830438.3830957
FUNARCH '26: "From Lambda to Ledger: An ..."
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.
Article Search
Article: icfpws26funarchmain-p2-p doi:10.1145/3830438.3830956
FUNARCH '26: "Functional State Machines ..."
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.
Article Search
Article: icfpws26funarchmain-p6-p doi:10.1145/3830438.3830958