🔬 The lab — proof by use

Amalgame Lab

A language is only worth what you build with it. This is the workshop: real projects — some in production, some still on the bench — each chosen to prove a specific point. The web server that serves this page. A P2P orchestrator. A weather station on a Raspberry Pi. The same amc, from datacenter to sensor.

Mosaic
🟢 In production — this site runs on it

Mosaic — the web, served by Amalgame

amalgame.me · docs.amalgame.me · demo.amalgame.me · client sites

The page you're reading is served by a single native binary written in Amalgame. No Node, no nginx in front, no reverse proxy: the binary terminates TLS itself, picks the right site from the Host header (SNI), and serves everything on port 443. The HTTPS certificate is obtained and renewed by a pure-Amalgame ACME state machine (RFC 8555, Let's Encrypt) — no certbot, no subprocess.

One process, several domains, static and dynamic content (the Releases page is filled live from the GitHub API; the contact form verifies a reCAPTCHA server-side, then sends mail over SMTP/TLS). It's the ultimate dogfooding: if Mosaic didn't hold up, this site would be down.

Automatic HTTPS via native ACME — one domain, one email, the binary does the rest
Multi-site SNI — one :443 listener, N domains, one certificate per domain
Static + dynamic — files served with ETag/304, application routes right beside them
L7 security — strict headers (HSTS/CSP), CSRF, rate-limit, anti-slowloris
Contact form — server-side reCAPTCHA + SMTP/TLS mail send, end to end
No heavy deps — OpenSSL 3.x, and that's it. No mystery runtime

The skeleton, as it runs here — one binary, many hosts. (Sensitive code — reCAPTCHA keys, SMTP credentials — lives outside the source, never in the repo.)

let server = SiteServer.New()

// One site = one folder. Several domains can point at it.
server.Register(["docs.amalgame.me"], "sites/docs.amalgame.me")
server.Register(["demo.amalgame.me"], "sites/demo.amalgame.me")
server.RegisterAmalgameWithContact(
    ["amalgame.me", "www.amalgame.me"], "sites/www.amalgame.me", releases,
    cfg)   // cfg = secrets loaded at runtime, not in the repo

// Native ACME per domain, then a single HTTPS listener + SNI.
server.EnsureCerts()
server.ListenHttps(443)   // :80 redirects 301 to https://
Pollen
🟡 In progress — already working

Pollen — P2P orchestration, no broker

peer-to-peer bus · declarative workflow · zero central infra

Where Mosaic proves Amalgame does web, Pollen proves it does distributed systems. It's a peer-to-peer data bus and its orchestrator: no broker to provision, no cluster to maintain. Nodes talk directly (TCP + application-level ACK), and a shared workflow.json file tells each one what to do at every step — call, if, for, while, goto, persistent state.

Pollen is a demanding project — concurrency, low-level networking, a state machine — exactly the kind of thing you'd normally reach for Go or Rust to build. The fact that it's advancing in Amalgame, package after package, is the demonstration. The runtime lives in amalgame-pollen; a web UI (itself built on Mosaic) edits the workflows visually.

TCP transport + ACK at the application level, one JSON message per line
Declarative workflow engine — call / if / for / while / goto + state
Capability registry + power-of-two load balancing
Visual editor — a Mosaic web app draws and publishes the workflow
No broker, no cluster — no Kafka, no Zookeeper to operate
🔧 Build in progress — actual hardware

Weather station — Amalgame on a Raspberry Pi

Raspberry Pi Zero W · sensors · native ARM64 binary

Web and distributed systems are software. What remained was to prove Amalgame goes all the way down to hardware. The test bench: a weather station built on a Raspberry Pi Zero W and its sensors (temperature, humidity, pressure), driven directly from Amalgame. The same .am you write on your machine compiles to a native ARM64 binary and runs on the Pi — no embedded interpreter, no Python layer.

The pins go through amalgame-hardware-gpio, the first package in the Amalgame.Hardware family: digital GPIO via libgpiod v2 (the kernel-blessed API, valid from Pi 1 to Pi 5), with an API shape mirroring the upcoming bare-metal MCU HAL. I2C, SPI, PWM and UART — and therefore the station's sensors — land in the next phases. The build is in progress; the ARM64 pipeline (CI + releases) is already green.

Native ARM64 releases — Raspberry Pi OS 64-bit, built + tested in CI
amalgame-hardware-gpio v0.1 — digital GPIO via libgpiod v2, Pi 1→5
One codebase — from the dev box to the Pi, the same .am
Coming — I2C / SPI / PWM, a sensors package, and the station publishing its weather online

GPIO, HAL-style — the same API will read a sensor on the Pi today and a bare-metal MCU tomorrow.

import Amalgame.Hardware

let gpio = Gpio.New().AutoChip()      // detects RP1 (Pi 5) vs Pi 4-
gpio.PinMode(17, PinMode.Output)
gpio.DigitalWrite(17, Level.High)   // status LED: reading in progress

// I2C arrives in phase 2 → read a T°/humidity sensor directly.

What the workshop demonstrates

Three projects, three layers of the stack, one language and one compiler. That's the point: Amalgame isn't a syntax demo, it's a tool you ship with.

Web · in prod

It serves sites

This site, its docs, its demo and client sites all run on a single Mosaic binary, automatic HTTPS included.

Distributed · in progress

It orchestrates

Pollen does peer-to-peer and workflow without a broker — Go/Rust's usual turf, in Amalgame.

Embedded · in progress

It drives hardware

Native ARM64 binary on a Raspberry Pi, GPIO via libgpiod — from datacenter to sensor, one codebase.

Want to add your project to the workshop?

Amalgame is free (Apache-2.0) and installs in 30 seconds. Build something — and tell us about it.