Claude Code transcript

This is a collection of Gleam projects that serve as emulations of distributed protocols. Gleam is a type-safe functional language that runs on the Erlang/OTP virtual machine (BEAM).

Current sub-projects

The repo currently contains two Gleam projects:

• tutorial-vars/ — A project called "vars" that depends on gleam_stdlib, gleam_otp, envoy, and argv.
• otp_test/ — A project called "otp_test" that depends on gleam_stdlib, gleam_otp, and gleam_erlang.

Both use gleeunit for testing and target the Erlang/OTP runtime.

Purpose

The goal is to produce clean, understandable emulations of distributed protocols — prioritizing clarity over performance. Each sub-project is a standalone Gleam project with its own gleam.toml and source files.

Tooling

The repo includes custom Claude Code skills (in .claude/skills/) for:

• create-emulation.md — Creating new emulation projects
• gleam-otp.md — Working with Gleam OTP patterns
• jujutsu.md — Version control workflows

Done. Here's what was created:

kv_store/ project structure

• src/kv_store/server.gleam — KV server actor that stores Dict(String, String). Handles three message types:
• Put — inserts a key-value pair, returns OpError if the key already exists
• Get — returns the value or an error if the key is not found

• Delete — removes a key or returns an error if not found

• src/kv_store/client.gleam — Client actor that takes the server's Subject at startup. Sends 10 randomly chosen get or put requests (using a small pool of 5 keys to trigger collisions), then stops.

• src/kv_store.gleam — Main entry point that starts 1 server and 3 clients, kicks them off, and waits for completion.

Here's how the server works:

State

The server holds two things: a Dict(String, String) (the key-value store) and a self reference (its own Subject, not currently used but available for self-messaging patterns). It starts with an empty dict.

Message protocol

All three message types (Put, Get, Delete) follow the request-response pattern — each carries a reply_with subject that the server sends the result back on. This is what makes actor.call work: the caller blocks until the server sends a reply.

Handler logic

Put (lines 31-48): Checks if the key already exists via dict.has_key. If it does, the put is rejected and an OpError is sent back — the state is unchanged. If the key is new, it's inserted with dict.insert, and the server continues with the updated store.

Get (lines 51-63): Looks up the key with dict.get, which returns a Result. On Ok(value) it sends the value back; on Error it sends an error string. Either way, the state doesn't change.

Delete (lines 65-79): Same guard pattern as Put — checks dict.has_key first. If found, removes it with dict.delete and continues with the new store. If not found, returns OpError with the state unchanged.

Concurrency model

Because this is an OTP actor, messages are processed one at a time from a mailbox queue. Even with multiple clients sending requests concurrently, there are no race conditions — each Put/Get/Delete sees a consistent snapshot of the dict, and state updates are applied sequentially.

Public API (lines 96-109)

The put, get, and delete functions are convenience wrappers around actor.call with a 1-second timeout. They construct the appropriate message with a placeholder _ for the reply subject (which actor.call fills in automatically).