Deploy Koka to Europe โ Algebraic Effects on EU Infrastructure in 2026
Every function call has side effects. A database query reaches a server in Frankfurt. An HTTP request leaves the process. A random number generator reads entropy from the OS. A log message writes to stderr. These effects happen, they are real, and in most languages they are invisible โ the type system says nothing about them. A function that returns User might also send an email, mutate a cache, or exfiltrate data to a third-party analytics endpoint. The type says it returns a User. The side effects are not part of the contract.
Koka changes this. In Koka, side effects are part of the type. A function that reads from a database has type () -> <db> User. A function with no effects has type () -> total User. A function that might fail has type () -> <exn> User. These effect annotations are not optional comments or decorators โ they are checked by the compiler. You cannot write a function that secretly performs network I/O when its type says it is pure. The type system enforces the boundary between pure computation and effectful interaction.
Koka was created by Daan Leijen ๐ณ๐ฑ (Dutch, Microsoft Research) and is built on algebraic effects theory developed primarily by European researchers: Gordon Plotkin ๐ฌ๐ง at the University of Edinburgh, Matija Pretnar ๐ธ๐ฎ at the University of Ljubljana, and Andrej Bauer ๐ธ๐ฎ also at Ljubljana. The theory of algebraic effects and handlers โ the mathematical foundation underlying Koka's effect system โ was developed almost entirely within the European academic system. Koka makes this theory practical: zero-overhead effect handlers, Perceus reference counting that eliminates garbage collection pauses, and a clean functional syntax that makes effect-safe web backends straightforward to write.
Koka applications deploy to sota.io on EU infrastructure with full GDPR compliance. This guide shows how.
The European Koka Team
Koka's design and the algebraic effects theory it implements are rooted in European programming language research.
Daan Leijen ๐ณ๐ฑ โ Dutch computer scientist, principal researcher at Microsoft Research โ created Koka. Leijen began the Koka project as a research vehicle for exploring algebraic effects as a practical programming model, first presenting the language at HOPE 2012. His subsequent papers โ "Algebraic Effects for Functional Programming" (2016), "Structured Asynchrony with Algebraic Effects" (2017), and the Koka 2 series โ developed Koka from a research prototype into a language with a complete standard library, a Node.js backend, a C backend, and a performant compiled implementation. Leijen is also the author of Perceus: the reference counting memory management system at the heart of Koka's performance story. Perceus ("Precise Reference Counting with Reuse and Sharing") was published at PLDI 2021 and demonstrated that reference counting with compile-time reuse analysis can match or exceed garbage collector performance for functional programs โ eliminating GC pauses entirely while maintaining the allocation patterns of a GC language. Leijen's work on Koka represents one of the most sustained engineering efforts in the algebraic effects space: bridging from pure mathematical theory to a language that can compile real applications to efficient machine code.
Gordon Plotkin ๐ฌ๐ง โ British computer scientist, Professor Emeritus at the University of Edinburgh โ co-authored with Matija Pretnar the foundational papers on algebraic effects and handlers. Plotkin and Pretnar's 2009 paper "Handlers of Algebraic Effects" (at GLL) and their 2013 paper in the Journal of Logical and Algebraic Methods in Programming established the formal semantics for computations with algebraic effects โ the denotational model where effects are described by algebraic theories and handlers are homomorphisms of those algebras. Plotkin is one of the founders of denotational semantics and domain theory; his contribution to algebraic effects connected the foundations of theoretical computer science to a practical programming language feature. Edinburgh's Laboratory for Foundations of Computer Science has been central to algebraic effects research for two decades.
Matija Pretnar ๐ธ๐ฎ โ Slovenian computer scientist, Associate Professor at the University of Ljubljana โ co-developed with Plotkin the algebraic effects and handlers theory and created Eff, the first practical programming language with algebraic effects (2011). Pretnar's PhD thesis "Logic and Handling of Algebraic Effects" (Edinburgh, 2010) is the foundational reference for effect handlers as a language construct. His work with Plotkin gave Koka its theoretical core: the idea that computational effects can be described as algebraic operations, and effect handlers as the mechanism for interpreting those operations. Pretnar continues algebraic effects research at the University of Ljubljana ๐ธ๐ฎ, including work on efficient compilation of effect handlers.
Andrej Bauer ๐ธ๐ฎ โ Slovenian mathematician, Professor at the University of Ljubljana โ co-created Eff with Pretnar and has been the primary advocate for algebraic effects as a unifying framework for computational effects. Bauer's blog posts, papers, and talks have been instrumental in spreading algebraic effects from the theory community to practical language designers. His "An introduction to algebraic effects and handlers" (2015) remains the most-cited accessible treatment of the subject. Ljubljana has functioned as the algebraic effects research hub for Europe โ a Slovenian university contributing mathematical foundations that shape a Dutch researcher's practical language design at Microsoft Research Cambridge.
Ningning Xie (Cambridge) โ co-authored with Leijen the ICFP 2021 paper "Generalized Evidence Passing for Effect Handlers" โ the compiler technique underlying Koka 2's efficient effect handler implementation. This work showed how to compile algebraic effect handlers to efficient code by passing evidence (dictionaries of effect operations) through the call stack, analogous to Haskell's typeclass evidence passing but extended to computational effects. The result: effect handlers with performance comparable to monadic code, without the syntactic overhead of monad transformers.
Why Koka for EU Backends
Side effects are visible in types. In Koka, every function's type declares what effects it can perform. fun greet() : total string โ pure, no effects. fun readUser(id: Int) : <db,exn> User โ reads from a database, may throw an exception. fun trackPageView(url: String) : <http,log> () โ performs HTTP and writes a log. The effect annotations are checked by the compiler. A function typed as total cannot call a database function. A function with <db> effects cannot perform <network> operations without declaring them. For EU backend services processing personal data, this means the compiler enforces data flow boundaries at compile time: you cannot accidentally send user data to an analytics endpoint from a function typed as having only <db> effects.
Zero-overhead effect handlers. Koka's effect handlers compile to efficient code via evidence passing. Tail-resumptive handlers โ handlers that resume their continuation exactly once at the end โ compile to simple loops with no heap allocation, no continuation capture, no coroutine machinery. The common patterns of effect handling (iteration, optional, state, reader) incur no runtime overhead beyond what a direct implementation would. Non-tail-resumptive handlers (handlers that resume their continuation zero or multiple times, for non-determinism or coroutines) require continuation capture but are optimised via stack segmentation. For EU web backends where latency matters โ GDPR-compliant personal data processing under Article 22's right to timely responses โ zero-overhead effects mean you do not pay a runtime cost for the type-level compliance guarantees.
Perceus reference counting eliminates GC pauses. Koka uses Perceus: a precise reference counting system with compile-time reuse analysis. When Koka can prove that a reference-counted value is uniquely referenced at the point of mutation, it rewrites the allocation to reuse the existing memory cell instead of allocating a new one. map f list over a list whose reference count is 1 at the call site reuses each cons cell rather than allocating a new one โ the operation becomes in-place even though the source code is purely functional. For EU services with latency SLAs โ GDPR Article 83 compliance systems, financial transaction processors under MiFID II, healthcare record APIs under the EU Medical Device Regulation โ the absence of GC pauses means latency is bounded and predictable rather than subject to stop-the-world collection events.
Effect polymorphism composes cleanly. Koka functions are polymorphic over effects. fun map(l: list<a>, f: (a) -> e b) : e list<b> โ the map function propagates whatever effects its argument function has. If f reads a database (<db>), then map(users, f) has type <db> list<b>. You do not need monad transformer stacks, MTL typeclasses, or IO threading โ effects compose automatically through the type inference system. For EU backend code with complex data processing pipelines (GDPR data subject access requests that touch multiple data stores, financial reports that aggregate from multiple regulated sources), effect polymorphism means the effect tracking is sound end-to-end without requiring manual threading of effect contexts through every function signature.
Algebraic effects replace exception hierarchies cleanly. In Koka, exceptions are just one instance of algebraic effects. You define your own effect for each error domain: effect httpError { fun badRequest(msg: string): a; fun unauthorized(): a }. Handlers for these effects handle each operation case. This is more composable than exception hierarchies: handlers can resume after handling an error (retry semantics), transform errors to different types, or accumulate error lists (applicative validation). For EU services that must produce structured audit logs of errors under GDPR Article 30 (Records of Processing Activities), effect-based error handling makes the complete error domain explicit and compiler-verified.
C backend for performance-critical EU services. Koka compiles to C via koka --backend=c, producing efficient machine code via system C compilers. The C backend implements Perceus reference counting, tail call optimisation, and evidence passing directly. For EU compute backends that need native performance โ GDPR anonymisation pipelines processing large datasets, cryptographic computation under eIDAS, scientific computation for EU regulatory reporting โ Koka's C backend provides systems-language performance from purely functional code.
Koka Language Essentials
Koka's syntax is clean and expression-oriented. Functions, effects, and handlers are first-class:
// Pure function โ no effects
fun greet(name: string): string
"Hello, " ++ name
// Effect declaration
effect db
fun query(sql: string, params: list<string>): list<row>
fun execute(sql: string, params: list<string>): int
// Effect declaration for errors
effect httpError
fun badRequest(msg: string): a
fun notFound(resource: string): a
fun unauthorized(): a
// Function using effects โ type inferred as <db, httpError> user
fun getUser(id: int)
val rows = query("SELECT * FROM users WHERE id = $1", [show(id)])
match rows
[] -> notFound("user/" ++ show(id))
[row, ..] -> parseUser(row)
// Handler โ interprets the db effect against a real PostgreSQL connection
fun withDb(conn: pgConn, action: () -> <db|e> a): e a
handle action
return(x) -> x
query(sql, params) -> resume(pgQuery(conn, sql, params))
execute(sql, params) -> resume(pgExecute(conn, sql, params))
Effect handlers separate the description of effectful computation from its interpretation. The getUser function describes what it needs (a database query); the withDb handler provides the interpretation (PostgreSQL connection). For testing, you replace withDb with an in-memory handler โ no mocking framework required, just a different handler:
// Test handler โ in-memory database, no network required
fun withTestDb(store: ref<list<row>>, action: () -> <db|e> a): e a
handle action
return(x) -> x
query(_, _) -> resume(!store) // dereference ref to get test data
execute(_, _) -> resume(1)
// Test runs against in-memory data โ same business logic, different handler
test "getUser returns user when present"
val testData = [row(["id"=>"1", "email"=>"user@example.com"])]
val store = ref(testData)
val result = withTestDb(store) { getUser(1) }
expect(result.email == "user@example.com")
The effect system makes the test boundary explicit: getUser has type <db, httpError> user; the test handler satisfies the db effect, leaving httpError handled by the test framework.
Effect-Safe GDPR Data Pipelines
Effect types provide compile-time guarantees about data exfiltration โ the core requirement for GDPR Article 25 (Data Protection by Design):
// Effects that can touch personal data
effect personalDataStore
fun readSubject(id: UserId): subject
fun deleteSubject(id: UserId): ()
fun exportSubject(id: UserId): gdprExport
// Effects that can reach outside the EU
effect externalNetwork
fun httpPost(url: string, body: string): response
// GDPR access request handler
// Type: <personalDataStore, log> gdprExport
// Compiler verifies: this function CANNOT perform externalNetwork
fun handleAccessRequest(requestId: RequestId, subjectId: UserId)
log("GDPR access request " ++ show(requestId) ++ " for subject " ++ show(subjectId))
val export = exportSubject(subjectId)
log("Access request " ++ show(requestId) ++ " fulfilled โ " ++ show(export.recordCount) ++ " records")
export
// The compiler rejects this โ handleAccessRequest cannot call httpPost
// because its effect signature does not include externalNetwork:
//
// fun handleAccessRequest(requestId, subjectId)
// val export = exportSubject(subjectId)
// httpPost("https://analytics.example.com/track", toJson(export)) // COMPILE ERROR
// export
The type system enforces the GDPR data boundary at compile time: functions that handle personal data cannot accidentally call functions with externalNetwork effects. The compiler is the data protection auditor.
HTTP Services with Koka
Koka's standard library includes std/net/http for building HTTP services, and the Node.js backend enables deployment alongside existing infrastructure:
import std/net/http
import std/data/json
effect userService
fun createUser(email: string, name: string): user
fun getUser(id: int): maybe<user>
// HTTP handler โ effects are <userService, httpError>
fun handleCreateUser(req: request): <userService, httpError> response
val body = match fromJson(req.body)
Error(msg) -> badRequest("Invalid JSON: " ++ msg)
Ok(json) -> json
val email = match body.field("email")
Nothing -> badRequest("Missing required field: email")
Just(v) -> v.asString
val name = match body.field("name")
Nothing -> badRequest("Missing required field: name")
Just(v) -> v.asString
val user = createUser(email, name)
response(201, toJson(user))
// Wire up the server with concrete handlers
fun main()
val port = 8080
withPostgresUserService(pgConfig) {
withHttpErrorHandler {
serve(port) { req ->
match req.path
"/users" | req.method == "POST" -> handleCreateUser(req)
_ -> response(404, "Not found")
}
}
}
println("Listening on port " ++ show(port))
The effect types make the dependency graph of each HTTP handler explicit: handleCreateUser requires userService and may raise httpError. The main function satisfies both effects with concrete handlers. Swapping PostgreSQL for an in-memory store for integration tests requires changing one handler, not refactoring the handler logic.
Deploy to sota.io
FROM node:20-slim
# Install Koka
RUN apt-get update && apt-get install -y curl git cmake && \
curl -sSL https://github.com/koka-lang/koka/releases/latest/download/install.sh | bash
WORKDIR /app
COPY . .
# Compile Koka to JavaScript via Node.js backend
RUN koka --backend=node -o dist/server.mjs src/server.kk
EXPOSE 8080
CMD ["node", "dist/server.mjs"]
# Install sota CLI
curl -fsSL https://sota.io/install.sh | sh
# Authenticate
sota auth set-key YOUR_API_KEY
# Deploy from project directory
sota deploy
Your Koka service is live at your-project.sota.io on German infrastructure within minutes.
EU Infrastructure and GDPR Compliance
Koka effect handlers (effect-safe computation)
โ
Node.js / C runtime
โ
sota.io platform
โ
Hetzner Germany (Frankfurt)
โ
EU jurisdiction โ no Cloud Act exposure
Deploying on sota.io means:
- No US Cloud Act jurisdiction โ sota.io is a German company. Hetzner is a German company. No US corporate parent can receive a CLOUD Act production order for your EU users' data.
- GDPR Article 28 DPA โ Data Processing Agreement available on request.
- Data residency guarantee โ your PostgreSQL database and application containers run in Germany.
- TLS by default โ HTTPS certificate provisioned automatically.
- Effect-type enforcement โ Koka's algebraic effect system provides compile-time guarantees that your data processing functions cannot perform unintended side effects, complementing infrastructure-level GDPR controls with type-system-level data protection.
For EU services processing personal data โ healthcare record APIs under the EU Medical Device Regulation, financial APIs under MiFID II, any service subject to GDPR Articles 25 and 32 โ Koka's effect types provide a programming model where data protection is enforced by the compiler, and sota.io provides the infrastructure where data residency is enforced by jurisdiction.
Getting Started
Install Koka:
# macOS
brew install koka
# Linux (installer script)
curl -sSL https://github.com/koka-lang/koka/releases/latest/download/install.sh | bash
# Windows (PowerShell)
winget install koka
Create your first effect-safe Koka program:
// hello.kk
effect greet
fun sayHello(name: string): ()
fun main(): <greet> ()
sayHello("EU")
fun withConsoleGreet(action: () -> <greet|e> a): e a
handle action
return(x) -> x
sayHello(name) -> { println("Hello, " ++ name ++ "!"); resume(()) }
fun run()
withConsoleGreet { main() }
# Run Koka program
koka src/hello.kk
# Compile to C for production performance
koka --backend=c -o hello src/hello.kk
./hello
# Compile to Node.js for web deployment
koka --backend=node -o hello.mjs src/hello.kk
node hello.mjs
Deploy to sota.io:
# Install sota CLI
curl -fsSL https://sota.io/install.sh | sh
sota auth set-key YOUR_API_KEY
sota deploy
Your Koka service is live at your-project.sota.io on German infrastructure within minutes.
sota.io is the EU-native PaaS for Koka and effect-safe functional backends โ GDPR-compliant infrastructure, managed PostgreSQL, and zero-configuration TLS. Deploy your first Koka application โ