Wyzer merges Perceus memory management with choreographic programming

A developer has published Wyzer, a statically typed, compiled, resource-oriented programming language, as a Show HN post on GitHub. The project's pitch is a single ownership rule that unifies safety across three areas that normally require separate tools: memory management, concurrency, and distributed or networked correctness. For memory, Wyzer replaces both garbage collection and Rust-style borrow checking with a Perceus reference-counting model, which the author says was borrowed from the Koka and Lean 4 languages. For distributed and concurrent code, it uses choreographic programming, an approach the author describes as borrowed from academic research: a single network rule is written once and the compiler generates matching code for every machine involved. The author's stated novelty is extending that same choreography rule beyond networking to threads and interrupts as well, so the identical rule is used to prove memory safety, interrupt safety, and network safety together, rather than reaching for a different tool for each. The author frames this against the two dominant approaches in use today. Rust delivers safe memory without a garbage collector but is described as hard to learn, with rules that make some common code structures difficult to write; languages with garbage collectors, such as Go, Java, C#, and Python, are easier to use but slower and less predictable, which the author calls unsuitable for real-time or low-level systems. On the network side, the author argues that Rust's guarantees stop at the edge of a single process. It does nothing for distributed deadlocks, protocol mismatches, or cross-service correctness, and that network programming today is still mostly done by hand, with two separate programs expected to agree on a protocol and no automatic check when they do not. In Wyzer, the compiler is meant to derive network rules from ownership types and check them automatically, catching deadlocks and dropped messages before the code runs. The language syntax shown in the documentation includes immutable-by-default variables (made mutable with var, or fixed at compile time with const), struct-defined data types with direct field access, if/else and loop constructs that do not require parentheses around the condition, and a Result type with match expressions for handling success and failure explicitly, with no async/await split and no hidden exceptions. The README opens with a quote from Atiksh Sharma: "Simplicity is not the absence of power. It is power without pretense." The author is candid that the project is early-stage: several big problems are described as still unsolved, and the README states that AI assistance was used for generating commit messages, for researching choreographic programming and the Perceus memory model, and for ideas in designing the project's logo and branding. The material does not give a version number, license, release status, performance benchmarks against Rust or other languages, a production timeline, or the name and affiliation of whoever wrote or maintains the project beyond first-person references in the README.

Key facts

Wyzer is a statically typed, compiled, resource-oriented programming language published on GitHub as a Show HN post.
It replaces garbage collection and Rust-style borrow checking with a Perceus reference-counting memory model, which the author says is borrowed from the Koka and Lean 4 languages.
It applies choreographic programming, an approach the author describes as borrowed from academic research, not just to networking but also to threads and interrupts, using the same rule to prove memory, interrupt, and network safety together.
The author argues Rust guarantees safety only within a single process and does nothing for distributed deadlocks, protocol mismatches, or cross-service correctness, gaps Wyzer aims to close with the compiler deriving and checking network rules from ownership types.
The author says AI was used to generate commit messages, to research choreographic programming and the Perceus memory model, and to help design the project's logo and branding, and calls the project early research with several big problems still unsolved.

Why it matters

Most languages need separate tools to keep memory, concurrency, and networked code safe: a borrow checker or garbage collector for memory, and hand-written protocols for cross-service correctness that fail silently when two programs disagree. Wyzer's pitch is a single ownership rule covering all three: once a resource, whether a block of memory, a network message, or a hardware interrupt, has been used, it cannot be used again, and the compiler enforces this uniformly rather than through separate mechanisms. The author positions this against the two approaches in wide use today. Rust delivers memory safety without a garbage collector but is described as hard to learn, with rules that make some common code structures difficult to write. Garbage-collected languages such as Go, Java, C#, and Python are easier to use but slower and less predictable, which the author calls a problem for real-time or low-level systems. On networking specifically, the author argues that Rust's guarantees end at the boundary of one process: it does nothing for distributed deadlocks, protocol mismatches, or cross-service correctness, and today those problems are mostly handled by writing two separate programs and hoping they agree on a protocol.

Who it affects

The project targets systems and network programmers who currently combine separate tools for memory safety and distributed correctness, along with developers frustrated by Rust's borrow checker or by the unpredictability of garbage-collected runtimes in low-level or real-time code. The author explicitly invites contributors, pointing them to a RESEARCH.md file in the repository and a Discord server, and frames Wyzer as early-stage research rather than something production teams should adopt today.

How to use it

Wyzer is statically typed and compiled. Variables are immutable by default; the var keyword makes a variable mutable, and const declares a compile-time constant. Custom data types are defined with struct, with direct access to their fields. The language supports standard if/else, while, and for loops that do not require parentheses around the condition. Functions that can fail return a Result<T, E>, and match expressions handle the Ok and Err cases explicitly, with no async/await split and no hidden exceptions. The source, documentation, a RESEARCH.md file for contributors, and an example program, a torus-drawing 'donut' demo ported into the language, are on GitHub. No license, version number, or release status is given in the material reviewed.

How solid is it

Wyzer's two core techniques are not new by themselves. Perceus reference counting is borrowed from the Koka and Lean 4 languages, and choreographic programming, writing one network rule that generates matching code for every machine, is borrowed from academic research where, per the author, it has mostly stayed confined to research settings rather than general-purpose languages. What the author presents as new is applying that same choreography rule beyond networking to threads and interrupts, so one rule proves memory safety, interrupt safety, and network safety together. The author is direct about the project's stage, calling it early research with several big problems still unsolved, and discloses that AI assistance was used for commit messages, for researching the underlying choreographic-programming and Perceus concepts, and for logo and brand design. No performance benchmarks against Rust or other languages, and no production timeline, are given.

Risks and caveats

The claims in the README are the author's own framing and are not backed, in the material reviewed, by benchmarks, a license, a version number, or a production timeline. The author states that choreographic programming remains mostly a research technique rather than one proven in general-purpose languages, and describes Wyzer itself as early research with unsolved problems still open. The source does not identify who wrote or maintains Wyzer beyond first-person references in the README, so no name or affiliation can be attached to the author here.

“Simplicity is not the absence of power. It is power without pretense.”

— Atiksh Sharma, quoted at the top of the Wyzer README