sota.io
2026-04-02·9 min read·sota.io team

Deploy Modula-2 to Europe — Niklaus Wirth 🇨🇭 ETH Zürich + The Language That Invented Modules on EU Infrastructure in 2026

On January 1, 2024, Niklaus Wirth died at his home in Feldmeilen, near Zürich, Switzerland. He was 89 years old. He had spent his entire career at ETH Zürich — the Swiss Federal Institute of Technology — designing programming languages with a philosophy that the industry has spent fifty years slowly rediscovering: programs should be simple, correct, and small. Compilers should be fast enough to not interrupt thought. Languages should express intent, not machine mechanics.

Wirth created four major languages in his career: Pascal (1970), Modula (1975), Modula-2 (1978), and Oberon (1988). Each one was a refinement of the last. But it is Modula-2 that left the deepest structural mark on modern programming — not through direct use, but through the idea it introduced: the module.

Before Modula-2, there were no modules. There were files, there were procedures, there were global variables. There was no formal unit of encapsulation that separated interface from implementation, that could be separately compiled, that enforced the boundary between what a component exports and what it hides. Modula-2 invented that. Go's packages, TypeScript's modules, Rust's crates, Python's __init__.py conventions — every modular system in modern programming descends from the idea Wirth worked out at ETH Zürich in 1978.

Niklaus Wirth and ETH Zürich

ETH Zürich (Eidgenössische Technische Hochschule Zürich) is the Swiss Federal Institute of Technology, founded in 1854 in Zürich, Switzerland. It is consistently ranked among the world's top universities in science and engineering — alongside MIT and Cambridge — and it has been the home of disproportionate fraction of fundamental computing research.

Niklaus Wirth 🇨🇭 was born in 1934 in Winterthur, in the canton of Zürich. He studied electronics at ETH Zürich, then moved to the University of Laval in Québec for his master's, then to UC Berkeley for his PhD (1963), where he worked under Harry Huskey on the design of the Euler language. He returned to Switzerland in 1967 to join ETH Zürich's faculty, where he would remain for the rest of his working life.

In 1968 he designed PL360 — a structured language for the IBM System/360 — and in 1970 he published Pascal, named after the French mathematician Blaise Pascal. Pascal became one of the most widely taught programming languages in history: through the 1970s and 1980s, Pascal was the standard language of computer science education across Europe and the United States. The language's clean syntax, strong type system, and structured control flow showed that programming could be taught as an intellectual discipline rather than a collection of machine-specific tricks.

But Pascal had a problem. It was designed for complete programs compiled as a single unit. As programs grew larger, developers needed a way to organise code into separately compiled units with explicit interfaces. Pascal offered no mechanism for this. Wirth's answer was Modula-2.

In 1976–1977, Wirth visited Xerox PARC in California on sabbatical. PARC was then the most productive computer science research laboratory in the world — the birthplace of the personal computer, the graphical user interface, Ethernet, and the laser printer. At PARC, Wirth encountered the Mesa programming language, which had a module system. He returned to ETH Zürich with the insight that would become Modula-2's defining feature.

Wirth received the ACM Turing Award in 1984 — computing's Nobel Prize — for developing Pascal, Modula, and Modula-2 and for demonstrating that programming languages could be elegant, teachable, and practically useful simultaneously. He was 50 years old. He spent the next twenty years at ETH Zürich, continuing to refine his ideas through Oberon before retiring in 1999. He died on New Year's Day, 2024.

Why Modula-2: The Problem Pascal Could Not Solve

Pascal's fatal limitation for systems programming was the absence of separate compilation with explicit interfaces. In Pascal, everything was a single program unit. You could not write a library, define its interface precisely, and compile it independently from the program that uses it. There was no formal mechanism to say: "this component exports these procedures with these types, and hides everything else."

This mattered enormously for operating system development. Wirth wanted to build a real operating system at ETH Zürich — the Lilith personal workstation project, running the Medos operating system, all written in Modula-2. An operating system consists of components that must be compiled independently, that must enforce strict interface boundaries between the kernel, device drivers, the file system, and user programs. Pascal could not express this cleanly.

Modula-2 solved it with three complementary mechanisms:

Definition modules (.def files) declare the interface: the types, constants, procedures, and variables that a module makes available to the outside world. The definition module is the contract — the API specification that client code depends on.

Implementation modules (.mod files) contain the actual code. The implementation can be changed as long as it satisfies the definition. Client modules that import the definition do not need to be recompiled when the implementation changes — only when the interface changes.

Import statements make the dependency structure explicit and verifiable. Every name used from another module must be explicitly imported. There are no implicit namespaces, no accidental collisions between module-internal names.

(* Definition module: the interface contract *)
DEFINITION MODULE EUDatabase;

TYPE
  DataSubject = RECORD
    id        : LONGINT;
    email     : ARRAY [0..127] OF CHAR;
    consentTS : LONGINT;  (* Unix timestamp of GDPR consent *)
    retained  : BOOLEAN;
  END;

PROCEDURE InsertSubject(VAR ds: DataSubject): BOOLEAN;
PROCEDURE FindSubject(id: LONGINT; VAR ds: DataSubject): BOOLEAN;
PROCEDURE EraseSubject(id: LONGINT): BOOLEAN;  (* GDPR Art. 17 right to erasure *)

END EUDatabase.

(* Implementation module: the actual code *)
IMPLEMENTATION MODULE EUDatabase;

IMPORT SYSTEM, PostgreSQL;

VAR
  conn : PostgreSQL.Connection;

PROCEDURE InsertSubject(VAR ds: DataSubject): BOOLEAN;
BEGIN
  (* Implementation hidden from callers *)
  RETURN PostgreSQL.Execute(conn,
    "INSERT INTO subjects (id, email, consent_ts, retained) VALUES ($1, $2, $3, $4)",
    ds.id, ds.email, ds.consentTS, ds.retained);
END InsertSubject;

PROCEDURE EraseSubject(id: LONGINT): BOOLEAN;
BEGIN
  (* GDPR Article 17: Right to erasure — implemented, not just documented *)
  RETURN PostgreSQL.Execute(conn,
    "DELETE FROM subjects WHERE id = $1 AND retained = FALSE", id);
END EraseSubject;

END EUDatabase.

The client module that uses EUDatabase sees only what the definition module declares. It cannot accidentally access the conn variable — the PostgreSQL connection handle — because conn is declared in the implementation module, not the definition module. This is not merely a convention; it is enforced by the compiler.

This separation of interface and implementation — design-time contract from compile-time code — is the structural idea that Go's package system, Java's interface declarations, TypeScript's .d.ts files, and Rust's pub visibility system all express in different syntactic forms.

Modula-2 in 2026: GNU Modula-2 (gm2)

The most practical implementation of Modula-2 today is GNU Modula-2 (gm2), maintained by Gaius Mulley 🇬🇧 and included in GCC since GCC 13 (2023). Because gm2 is part of GCC, it is available in standard Linux package repositories. Any Ubuntu 23.10 or Debian 12 server has gm2 available with a single apt install command.

FROM ubuntu:24.04 AS builder

RUN apt-get update && apt-get install -y \
    gm2 \
    gcc \
    make \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# Definition module
COPY EUService.def /app/EUService.def
COPY EUService.mod /app/EUService.mod
COPY main.mod /app/main.mod

# Compile: definition modules first, then implementation, then main
RUN gm2 -fmod-version=2 -c EUService.mod && \
    gm2 -fmod-version=2 main.mod EUService.o -o server

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y libgcc-s1 && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/server /app/server
EXPOSE 8080
CMD ["/app/server"]

The main module for an HTTP server:

MODULE main;

FROM SYSTEM IMPORT ADR;
IMPORT EUService;
IMPORT IO;

VAR
  port : CARDINAL;

BEGIN
  port := 8080;
  IO.WriteString("sota.io Modula-2 service starting");
  IO.WriteLn;
  IO.WriteString("Niklaus Wirth, ETH Zürich, 1978");
  IO.WriteLn;
  IO.WriteString("Module system: interface/implementation separation since 1978");
  IO.WriteLn;
  EUService.Start(port);
END main.

The -fmod-version=2 flag selects Modula-2 as Wirth defined it in his 1985 textbook. gm2 also supports PIM2, PIM3, PIM4, and ISO Modula-2 variants — Wirth published several editions of the language specification, each refining the original design.

The Lilith Workstation: ETH Zürich Builds Its Own Computer

Between 1978 and 1980, Wirth and his team at ETH Zürich did not merely design Modula-2 — they built a complete personal workstation to run it. The Lilith computer was designed at ETH Zürich, with a custom processor (the M-code interpreter chip), a custom operating system (Medos, written entirely in Modula-2), a custom window system, and a custom development environment. The entire software stack, from the boot loader to the text editor, was written in Modula-2.

Lilith was operational in 1980, predating the IBM PC by one year and the Apple Macintosh by four years. It had a bitmapped display, a mouse, and a graphical user interface. The system demonstrated that a language designed for correctness and modularity could also support interactive applications, real-time response, and device driver development.

The Lilith project influenced Xerox PARC's later workstations, and through PARC, influenced the entire personal computer industry. The Swiss Federal Government funded the project through ETH Zürich — making Modula-2 one of the few programming languages whose development was funded by a European government research institution from the beginning.

GDPR and EU Regulatory Compliance

GDPR Article 25 — Privacy by Design and by Default

Modula-2's definition/implementation separation is a structural enforcement mechanism for data minimisation. A module that processes personal data can be designed so that the types and procedures involved in GDPR-regulated operations are precisely specified in the definition module, while the implementation details — the database connection, the internal representation, the indexing structures — are hidden. Client code cannot accidentally expose implementation details because the compiler enforces the module boundary.

This is not merely a matter of good practice. The module system makes it architecturally impossible for client code to access data that the definition module does not expose. GDPR Article 25's requirement for "data protection by design and by default" maps directly onto Modula-2's module system: the interface is the minimal necessary API, and the compiler guarantees that nothing beyond the interface is accessible.

GDPR Article 17 — Right to Erasure

Modula-2's strong type system and explicit module interfaces make it straightforward to audit compliance with the right to erasure. The EraseSubject procedure in the definition module is a declared, nameable, testable unit of GDPR compliance. Every code path that processes the deletion of personal data passes through an explicitly declared, separately compilable procedure. Auditors can trace the entire erasure flow from definition to implementation without navigating implicit dependencies or inherited behaviour.

EU AI Act Article 10 — Data Governance

The EU AI Act requires high-risk AI systems to have documented data governance procedures. Modula-2's definition modules serve as machine-readable data governance specifications: the types declared in a definition module describe the data structures that the module processes, and the procedures declared describe the operations performed on them. A definition module is simultaneously executable code and regulatory documentation.

NIS2 Directive — Critical Infrastructure

Modula-2's separate compilation model means that security-sensitive components can be isolated in their own modules with minimal interfaces. A cryptographic key management module can expose only the operations necessary for its clients — Encrypt, Decrypt, RotateKey — without exposing the key storage mechanism, the key derivation algorithm, or the internal entropy pool. NIS2's requirement for least-privilege architecture in critical infrastructure naturally maps onto Modula-2's module visibility model.

The ETH Zürich Legacy in EU Computing

The influence of ETH Zürich on European and world computing is difficult to overstate. The institution that produced Niklaus Wirth also produced:

Modula-2's influence on Go is direct and documented. Robert Griesemer — one of Go's three co-designers — is Swiss and received his doctorate at ETH Zürich under Niklaus Wirth. Go's package system, with its separation of exported identifiers (capitalised names) from unexported identifiers (lowercase names), is a syntactic rethinking of Modula-2's definition/implementation separation. Go's import statement is Modula-2's IMPORT statement with different syntax. The philosophy — explicit dependencies, module boundaries enforced by the compiler, no implicit global state — is Wirth's philosophy expressed in a language designed for Google-scale infrastructure.

Modula-3, a descendant designed in 1988 by a team including Luca Cardelli 🇮🇹 (then at DEC Systems Research Center in Palo Alto, now at Microsoft Research Cambridge 🇬🇧) and Greg Nelson at DEC SRC, added garbage collection and objects to the Modula-2 foundation. Modula-3 directly influenced Java's design — Mark Weiser at Xerox PARC wrote the first draft of what became Java's specification, and the language's module system and type discipline trace through Modula-3 to Wirth.

Deploy Modula-2 on sota.io

sota.io supports any language that compiles to a Linux binary or runs in a standard container. A Modula-2 application built with GNU Modula-2 (gm2) and containerised as shown above deploys with:

sota deploy --region eu-west

The platform detects the container, provisions EU infrastructure on Hetzner (Germany) or Scaleway (France), injects managed PostgreSQL credentials as environment variables, configures TLS termination, and assigns a .sota.io subdomain. All infrastructure runs within the European Economic Area.

For Modula-2 applications that need PostgreSQL, the recommended approach is the same as for other compiled languages: a C library wrapper for libpq (the PostgreSQL C client library), interfaced to Modula-2 through FOREIGN procedure declarations or through a thin C shim. gm2 generates standard ELF object files fully compatible with the GCC toolchain, so linking against C libraries is straightforward.

The architecture Wirth established at ETH Zürich in 1978 — explicit interfaces, separated modules, small trusted compilers — is the architecture that modern cloud systems are rediscovering. Microservices with explicit API contracts, infrastructure-as-code with declarative interfaces, type-safe RPC with protobuf definitions: these are all expressions of the insight that Modula-2 first formalised in machine-verifiable form.

ETH Zürich gave the world the module system in 1978. GNU Modula-2 is in GCC. The language runs on any Linux server in Europe.

See Also

sota.io is the EU-native platform-as-a-service for developers who need European infrastructure, GDPR compliance by default, and managed PostgreSQL without the operational overhead. Deploy your Modula-2 application to EU servers in minutes at sota.io.