Varyk - Blog

Varyk 0.9.0: errors in your editor

2026-10-12T00:00:00+00:00

Varyk 0.9.0 is on crates.io. It is the first release of milestone 6 on the roadmap: tooling. It brings three things:

varyk lsp, a language server, so the errors and fixes of varyk check show up in your editor;
a varyk-std line that names the oldest varyk a package needs, so a new varyk no longer breaks published packages;
Rust 1.88 as the minimum.

Errors in your editor

Until now, you saw Varyk's errors when you ran varyk check. Now your editor shows them. Each time you open or save a .vr file, varyk lsp checks the program the file belongs to, exactly as varyk check would. The editor underlines every error where it is, with its message, notes, and code. When an error has a suggested fix, the editor offers it as a quick fix. A fix can change another file: a missing pub is added where the item is declared.

The server checks what is on disk, so a fixed error disappears once you save. You never run varyk lsp yourself. The editor starts it. The reference explains which program a file belongs to.

The editor support lives in a new repository, varyk-editors:

VS Code, and the editors built on it: install Varyk from the Visual Studio Marketplace, or from Open VSX in VSCodium and the others that use it. It colours .vr files, toggles comments, matches brackets, indents, and starts varyk lsp. In a folder VS Code does not trust, it only highlights and runs nothing.
Zed: the Varyk extension is submitted to Zed's extension registry. It will be in the extensions panel as soon as the Zed team merges it. Until then, run "zed: install dev extension" and choose the zed/ folder of a checkout of varyk-editors. It is built on a Tree-sitter grammar, tree-sitter-varyk. It colours .vr files, gives you the outline panel, and starts varyk lsp. In a folder Zed does not trust, it only highlights and runs nothing.
JetBrains IDEs: colours, comment toggling, and bracket matching, through the TextMate Bundles setting pointed at the vscode/ folder of a checkout of varyk-editors. Its README has the steps. No diagnostics there yet: those need a plugin on the IDE's own language server API.
Any other editor that speaks the Language Server Protocol can run varyk lsp itself.

With varyk 0.9 on your PATH, there is nothing to set up. If it lives somewhere else, VS Code has a varyk.path setting. Highlighting never depends on the language server, so with an older varyk, or none, you still get colours.

Packages keep building

Up to 0.8, a program and every Varyk package in its build had to name the compiler's own minor version of varyk-std. So every minor release of the compiler, even one that changed nothing in varyk-std, broke every published package until that package released again. I did not want every varyk release to force a release of every package.

From 0.9, varyk-std = "0.8" means "needs varyk 0.8 or later". This varyk and every later one accept it, and the build always uses the compiler's own varyk-std, in the program and in every package. A compiler older than the line refuses it with V0404. From 0.9 on, that error says "this package needs varyk X.Y or later" and tells you to run cargo install varyk. When a package written for an older varyk does not pass the check, every error it shows gets one more note, here for a package called units: "units was written for varyk 0.8; a newer release of it may build with this compiler".

So varyk-http 0.2, varyk-sql 0.4, and varyk-mongo 0.1, all written for varyk 0.8, build with 0.9 as they are. No new releases needed.

varyk publish keeps the old, strict rule. A published crate is built by plain cargo from its own Cargo.toml and lock. Nothing rewrites them there. So you publish with a varyk on the minor your line names.

Rust 1.88

The compiler now needs Rust 1.88 or newer, up from 1.85, and CI checks it. varyk-mongo needed 1.88 from the start, for its MongoDB driver.

For Rust readers

Before 1.0, cargo treats varyk-std 0.8 and 0.9 as two different crates whose types do not mix. An open requirement like >=0.8 does not help either: cargo picks the newest release, which can be yet another minor. So I did not loosen the requirement. varyk already writes every manifest of the build under target/varyk/. Now it also puts its own varyk-std version in each one, so every Varyk crate of the build uses the same varyk-std. Your own Cargo.toml and Cargo.lock are left alone.

A package's Varyk code is generated by your compiler against that varyk-std, so it always matches. Only a package's own .rs files were written against an older one. If a newer varyk-std removed something they call, rustc says so at that file.

varyk lsp adds no dependency to the compiler. The protocol is JSON-RPC with Content-Length framing, read and written with the serde_json the compiler already uses, and positions are in UTF-16, the protocol's default.

What is not there yet

Hover, go-to-definition, and completion need a parser that recovers from an error and keeps going, and Varyk's does not yet. Checking as you type needs the server to read unsaved files and a checker fast enough to run on every keystroke. For now it checks on open and save. A file that no mod line reaches yet gets no errors until one does. The roadmap has the rest of milestone 6.

Upgrading

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.9.0. One thing is breaking: the compiler needs Rust 1.88, so run rustup update first if yours is older. Then cargo install varyk --locked.

A program written for 0.8 builds as it is, but move its varyk-std line anyway, and do it again after each new minor varyk. The build uses varyk-std 0.9. It never touches your Cargo.toml or Cargo.lock. So while the line says 0.8, the lock has no varyk-std 0.9, and every build asks crates.io for it again. Online, that is a bit slower. Offline, or in a CI job or container build without network access, the build fails. In the program's folder:

change the line to varyk-std = "0.9.0";
run cargo update -p varyk-std. Cargo may say the name is ambiguous. That happens when the lock also holds the varyk-std 0.8 that a package like varyk-http was written for. Then run cargo update -p varyk-std@0.9.0 instead.

Commit both files, and builds work offline again. A program made with varyk init 0.9 starts on the new line. The reference has the details.

To publish with varyk 0.9, move the line to 0.9 first: varyk publish wants the compiler's own minor and no older varyk-std anywhere in the build. A package that uses varyk-http, varyk-sql, or varyk-mongo is published with varyk 0.8 until the packages it uses have a release written for varyk 0.9. That goes for a library and for a program.

Try it

You need a stable Rust toolchain, 1.88 or newer, installed through rustup.

cargo install varyk --locked
varyk init hello
cd hello
varyk run

Then install the Varyk extension in VS Code, or in Zed once it is listed, open the folder, break something in src/main.vr, and save. Getting started goes on to a first service, and the language reference describes everything the compiler accepts.

What is next

The rest of milestone 6: varyk fmt, the rest of the language server, nested modules in .rs files, Rust tuple and unit structs imported from .rs files, Debug on imported Rust structs, and a decision on a native backend. Next to it, varyk-redis, the next package. None of it has a date.

Varyk is experimental and pre-1.0. Open a .vr file, save it with a mistake in it, and tell me where it hurts: the issues are the place.

varyk-mongo 0.1.0: MongoDB for Varyk

2026-10-10T16:30:00+02:00

varyk-mongo 0.1.0 is on crates.io. It is the official MongoDB package for Varyk, a language for backend services that compiles to Rust, over the official mongodb crate. It covers what an ordinary service does with MongoDB and nothing more: connect over TLS, read and write typed documents, filter with MongoDB's own operators, aggregate, index, run transactions, and test against a real server. It lives in its own repository, and its README is the full documentation. varyk-mongo is not affiliated with or endorsed by MongoDB, Inc.

Milestone 5 of the roadmap, the batteries for services, is complete, and varyk-mongo is the first of the next packages it lists after that, not a milestone of its own. Its work is done in a .rs facade over the driver, its tests against a real server are written in Varyk, and a program that uses it writes no Rust. The compiler side came as two patch releases, Varyk 0.8.1 and 0.8.2, and varyk-sql 0.4.0 came in the same round; all three are below.

Adding it

cargo install varyk --locked
varyk init users
cd users
varyk add mongo

varyk add mongo runs cargo add varyk-mongo --rename mongo, so the manifest gets mongo = { version = "0.1.0", package = "varyk-mongo" } and code names the package mongo::. varyk-mongo 0.1 works with Varyk 0.8.1 and later 0.8 releases, and programs that use it need Rust 1.88 or later, because the mongodb crate does; rustup update gets it. The compiler and the other packages stay at Rust 1.85.

A first program

src/main.vr:

struct Config {
    mongo_url: string,
}

struct User {
    #[rename("_id")]
    id: Uuid,
    email: string,
    name: string,
    created_at: Time,
}

async fn run() -> Result<bool, Error> {
    let config: Config = env::parse()?;
    let db = mongo::connect(config.mongo_url).await?;
    let users = db.collection("users");
    users.create_index("{ email: 1 }", "{ unique: true }").await?;

    users.delete_many("{ email: ? }", "ada@example.com").await?;   // a rerun starts clean
    let ada = User { id: Uuid::new(), email: "ada@example.com", name: "Ada", created_at: Time::now() };
    users.insert(ada).await?;

    let found: Option<User> = users.first("{ email: ? }", "ada@example.com").await?;
    let recent: Vec<User> = users.find("{ created_at: { $gte: ? } }", ada.created_at)
        .sort("{ created_at: -1 }").limit(20).all().await?;
    users.update("{ _id: ? }", "{ $set: { name: ? } }", ada.id, "Ada L.").await?;
    let gone: u64 = users.delete("{ _id: ? }", ada.id).await?;
    println!("{} {} {}", found.is_some(), recent.len(), gone);
    Ok(true)
}

async fn main() -> Result<bool, Error> {
    run().await
}

.env:

MONGO_URL=mongodb://127.0.0.1:27017/app

With a server running, varyk run prints true 1 1: Ada was found, she is the one recent user, and one document was deleted. The URL names the one database a service uses, and mongo::connect sends ping, so a wrong URL, a server that cannot be reached, or a refused password fails at startup rather than at the first request. #[rename("_id")] makes id the document's _id, and ada stays usable after users.insert(ada): the call reads the document and does not take it. The same program is in demo/users.

The calls

On a collection, one, first, all, and count read; find builds a query that sort, skip, and limit refine, and sends nothing until its one, first, or all; aggregate runs a pipeline. insert and insert_many write documents, update, update_many, upsert, and replace change them, delete and delete_many remove them, and create_index makes an index, which does nothing when it exists with the same options, so a service makes its indexes at startup. T comes from where the result goes, as in varyk-sql.

let user: User = users.one("{ email: ? }", email).await?;
let adults: u64 = users.count("{ age: { $gte: ? } }", 18).await?;
let page: Vec<User> = users.find("{ city: ? }", city)
    .sort("{ name: 1 }").skip(20).limit(10).all().await?;

let one: u64 = users.update("{ _id: ? }", "{ $set: { name: ? }, $inc: { age: 1 } }", id, "Ada L.").await?;
let added: bool = users.upsert("{ email: ? }", "{ $set: { name: ? }, $setOnInsert: { created_at: ? } }", email, name, Time::now()).await?;
let gone: u64 = users.delete_many("{ city: ? }", "Paris").await?;

The query text

Each text in quotes is MongoDB's own query syntax, as the shell and Compass write it, with ? where a value goes, and it is a literal string: a query built from input does not compile. The values follow the text, one per ?, from left to right across all the texts of the call. This is the package's guard against injection: a value is always data, so input cannot become an operator ({ "$ne": null }) or a part of the query. The rules that keep input out of the query are each an Error naming the place in the text, before anything is sent:

A value stands only where MongoDB reads plain data: anywhere in a filter, and in a top-level $match stage of a pipeline, except under $expr and $jsonSchema; as a value under $set, $setOnInsert, $inc, $mul, $min, $max, $push, and $addToSet, and in the condition of $pull; and as the number of a top-level $skip or $limit stage. Anywhere else MongoDB reads a string as a field path ("$passwordHash"), a variable, or a collection name, so a value from input could read another field or another collection.
A None cannot be matched. In a filter, a $match stage, or a $pull condition it is an Error, since { reset_token: null } matches every document without a reset token. Write null in the text to match a missing or null field; under $set a None stores null.
A value is never a pattern. A ? under $regex takes a string, and the package escapes every character with a meaning in a pattern, so users.all("{ name: { $regex: ?, $options: 'i' } }", search) finds every name that holds search, in any case, and nothing else.
No JavaScript on the server. $where, $function, and $accumulator are an Error as a key anywhere in a text.
? is never a key, a key written twice in one document is an Error, and the number of ?s must be the number of values.

The collection's name is a literal too, so input cannot choose which collection is read.

Documents and types

A document is written from a struct, and read into one, by field name; #[rename], #[skip], and #[default] work as they do for JSON. Time, Uuid, and Bytes are stored as real BSON types, so TTL indexes, date operators, Compass, and other drivers see dates, ids, and binary data as such:

Varyk	Stored as
`Time`	date, in milliseconds
`Uuid`	binary subtype 4, which Compass shows as `UUID("…")`
`Bytes`	binary
`Option`	null for `None`, the value for `Some`
`Vec<T>`	array
a struct, a `HashMap<string, V>`	embedded document

BSON dates hold milliseconds, so a Time's microseconds are dropped when it is stored, and a Time beside a text is rounded the same way, so a Time read back matches its own value. A new collection uses #[rename("_id")] id: Uuid and Uuid::new(), a new id ordered by time, as an ObjectId is. An existing collection whose _ids are ObjectIds reads them into a string as 24 hex digits and queries them with ObjectId(?).

Transactions

struct Order {
    #[rename("_id")]
    id: Uuid,
    item: string,
    count: i64,
}

async fn place(db: mongo::Database, order: Order) -> Result<bool, Error> {
    let mut tx = db.begin().await?;
    let orders = tx.collection("orders");
    let stock = tx.collection("stock");
    orders.insert(order).await?;
    let taken = stock.update("{ _id: ?, left: { $gte: ? } }", "{ $inc: { left: ? } }", order.item, order.count, -order.count).await?;
    if taken == 0 {
        return Err(Error::new("out of stock"));   // drops tx: rolls back the insert
    }
    tx.commit().await
}

A Tx dropped without commit rolls back, so an early return or a ? undoes it, as in varyk-sql. When a call inside the transaction fails in MongoDB, every later call on its collections is an Error without reaching the server, and commit rolls it back. A failure MongoDB calls temporary, a write conflict or an election, ends its message with "run it again", and the README shows a loop that does. Transactions need a replica set or a sharded cluster; Atlas is one. On a single server that is not a replica set, the first call inside a transaction is an Error saying so. For development, the README runs a replica set of one server in Docker; the package is tested against MongoDB 8.0.

When something goes wrong

Every failure is an Error whose message the package writes, and no call panics. A connection failure says which step failed and never contains the URL, so a password cannot reach a log that way. A mistake in a text names its place, and a value or a field that cannot be read names the value's number or the field, never the value. A server error keeps the server's message and code, and MongoDB puts the duplicate value in a duplicate-key message, so treat these messages as data: log them, and give clients a message of your own. The driver's command logging stays off, since it would log every command with its values, and the package logs nothing of its own. The driver is built with rustls and the webpki root certificates, so TLS works in a minimal container with no CA bundle and no OpenSSL.

What is not in it

A client with several databases; cursors; change streams; GridFS; bulk writes; find_one_and_update and the other find-and-modify calls; a projection; distinct; a transaction call that retries by itself; a pattern taken from input; a list beside the text ({ _id: { $in: ? } }: write one ? for each element); collection names chosen at run time; and Decimal128, regex, and timestamp values beside the text; the README has the full list. A document literal in the language, with values written inline, for MongoDB and JSON, is on the roadmap as unscheduled, with no date; until then varyk-mongo builds its documents from structs, and the literal's shape is an open question.

varyk-sql 0.4.0

varyk-sql 0.4.0 takes $1, $2, and so on, on every database, SQLite, Postgres, and MySQL, so the same placeholders work on all three:

let user: Option<User> = db.first("select id, name from users where id = $1", id).await?;

$2 may come before $1, and $1 may be written twice; it takes the same value each time. ? still works on SQLite and MySQL, one per value in order, so no query that bound correctly breaks. A $ inside a string, a quoted name, or a comment is text, not a placeholder. On SQLite and MySQL a query that mixes ? and $1, or numbers its placeholders other than $1 up to the number of values, each used, is an Error before it runs. varyk-sql's README now leads with $1, and so do this site's first service and the figure on the home page. No compiler change was needed.

Varyk 0.8.1 and 0.8.2

Varyk 0.8.1 is what lets varyk-mongo store Time, Uuid, and Bytes as BSON dates and binaries. A facade whose serializer is not human-readable, a binary database format, now gets a Time as its Unix microseconds and a Uuid as its 16 raw bytes, each in a form named in varyk_std::serde_names, and a Bytes as raw bytes, so it can store each as a native type. A human-readable serializer, JSON included, still gets the written string, so no output of an existing program changes. The reference has the sentence for facade authors.

Varyk 0.8.2 adds varyk add mongo, beside varyk add http and varyk add sql; a path starting mongo:: that names nothing gets a note that varyk add mongo adds varyk-mongo. It came after varyk-mongo 0.1.0 was on crates.io, so the short name never named a crate anyone else could register first.

Upgrading

cargo install varyk --locked

Then run varyk check in a package, and it says what to change, if anything: the varyk-std line in Cargo.toml, or cargo update -p varyk-std. Neither patch release breaks a program. To move to varyk-sql 0.4.0, change the version on the sql line in Cargo.toml to "0.4.0"; varyk add sql again does not do it, since cargo add keeps the version of a dependency the manifest already lists. varyk-sql 0.3 keeps working with Varyk 0.8.

varyk	varyk-sql	varyk-http	varyk-mongo
0.8	0.4 or 0.3	0.2	0.1 (Varyk 0.8.1 or later)

What is next

varyk-redis is the next package. Milestone 6 of the roadmap, tooling and beyond, with varyk fmt and a language server, is planned but not started, and has no date. Nothing on the roadmap is a date.

Varyk and varyk-mongo are experimental and pre-1.0. Point a small service at MongoDB and tell us where it hurts: the issues are the place.

Varyk 0.8.0: time, ids, and bytes

2026-10-07T00:00:00+00:00

Varyk 0.8.0 is on crates.io. It is milestone 5c of the roadmap, the last part of the batteries for services. Milestone 5b4 made the golden path: a users API on a database is varyk init, varyk add http sql, one file, and varyk run away. What that API could not say well was when a user was made: a created_at had to be a string. Milestone 5c adds three built-in types, Time, Uuid, and Bytes, known without a declaration, as Error is.

The two official packages follow it. varyk-sql 0.3.0 drops sqlx's Any driver for the concrete SQLite, Postgres, and MySQL pools, so the three types are native columns. varyk-http 0.2.0 reads a Time or a Uuid from a route, and sends and receives bytes: request and response bodies, uploads, binary WebSocket messages, and the client's bodies. Both need Varyk 0.8, and Varyk 0.8 needs them, since a program and its packages share one varyk-std. With them, milestones 5b4 and 5c are done, and milestone 5's bar is met.

What is in it

Time. One point in time in UTC, to the microsecond, from the year 0000 to the year 9999. Time::now() reads the clock. Time::from_iso(text) and text.parse() read RFC 3339 text, 2026-10-07T12:00:00Z, or one with an offset, which is taken to UTC; Time::from_unix(seconds) and Time::from_unix_micros(n) read a Unix time. to_iso, to_unix, and to_unix_micros go the other way, and {} prints what to_iso writes. t.add_seconds(n) and t.seconds_since(u) do the arithmetic, in whole seconds; + on a Time is an error. Times compare with ==, <, and the rest, a later time being the greater, and a Vec<Time> sorts, earliest first. Microseconds are what a Postgres timestamptz and a MySQL datetime(6) hold, so a time read back from the database equals the one written. No call of Time stops the program: each one that can leave the range, add_seconds among them, gives a Result.

Uuid. A 128-bit id. Uuid::new() makes a version 7, time-ordered, which keeps a primary key index compact; Uuid::v7() is the same, and Uuid::v4() makes a random one. A version 7 id holds the millisecond it was made in, readable by anyone who has the id, so a service that publishes ids and does not want their creation times known makes them with Uuid::v4(). text.parse() reads the 36-character form with hyphens, in either case, and {} writes it in lower case. Ids compare with == and !=, and a Uuid is a HashMap key; ids have no order.

Bytes. An immutable run of bytes: like a struct, a parameter borrows it, a field owns it, and let c = b moves it. Bytes::from_text and Bytes::from_base64 make one, to_text and to_base64 read it, and len and is_empty measure it. .clone() gives a second Bytes that shares the first one's buffer, with no byte copied. Bytes have no one printed form, so {} on a Bytes is an error whose note names to_text and to_base64, and the Err of from_base64 or to_text says what is wrong without repeating the bytes, which can be a whole request body.

Where they go. All three go through JSON, where a Time is RFC 3339 text, a Uuid its text with hyphens, and a Bytes standard base64 with padding; through assert_eq, and == and .clone() on a struct that holds them; as the values after a query; and in the signatures of a .rs facade. Time and Uuid also go through env::parse, parse, {}, and a route's path and query parameters, where text that does not read as the type is a 400 and the handler is not called. The compiler's new example, records, puts the three in one struct:

struct Upload {
    id: Uuid,
    at: Time,
    data: Bytes,
}

fn first_upload() -> Result<Upload, Error> {
    let id: Uuid = "0192F0C4-7A3E-7B5C-9D1E-2F3A4B5C6D7E".parse()?;
    let at = Time::from_iso("2026-10-07T12:00:00+02:00")?;
    Ok(Upload { id: id, at: at, data: Bytes::from_text("hello, world") })
}

// Writes `upload` as JSON, reads it back, and compares the two.
fn report(upload: Upload) -> Result<bool, Error> {
    println!("{} at {}", upload.id, upload.at);
    let expires = upload.at.add_seconds(3600)?;
    println!("expires at {}, {} seconds later", expires, expires.seconds_since(upload.at));
    let text = json::stringify(upload);
    println!("{}", text);
    let back: Upload = json::parse(text)?;
    Ok(back == upload)
}

The whole program, on the examples page, prints:

0192f0c4-7a3e-7b5c-9d1e-2f3a4b5c6d7e at 2026-10-07T10:00:00Z
expires at 2026-10-07T11:00:00Z, 3600 seconds later
{"id":"0192f0c4-7a3e-7b5c-9d1e-2f3a4b5c6d7e","at":"2026-10-07T10:00:00Z","data":"aGVsbG8sIHdvcmxk"}
read back the same: true
hello, world
aGVsbG8sIHdvcmxk
a new upload has its own id: true
`42` is not a Uuid like 01890a5d-ac96-774b-bcce-b302099a8057
`2026-10-07 12:00` is not a time like 2026-10-07T12:00:00Z

Facades. A .rs function, method, or pub field names the three by their full paths: varyk_std::Time and varyk_std::Uuid, copied as numbers are, &varyk_std::Bytes for bytes it only reads, and varyk_std::Bytes for bytes it takes. An imported enum may hold them in its variants, which is how varyk-http's WebSocket message carries a binary message.

There is no new diagnostic code: the existing ones gain cases, such as V0113 for a type named Time, V0200 for < on a Uuid, V0203 for {} on a Bytes, and V0219 for a Bytes path parameter. The reference has every call, and the error codes the full table.

varyk-sql 0.3.0

varyk-sql 0.3.0 is on crates.io. sqlx's Any driver, which served the three databases through one pool, has no date or uuid kind, so 0.3 holds one of the concrete pools, chosen from the URL's scheme as before, each behind its cargo feature. connect, Pool, Tx, and their calls are unchanged. The README's first service now stores a time:

struct User {
    id: i64,
    name: string,
    created_at: Time,
}

async fn load() -> Result<Vec<User>, Error> {
    let config: Config = env::parse()?;
    let db = sql::connect(config.database_url).await?;
    db.migrate("migrations").await?;
    db.run("insert into users (name, created_at) values (?, ?)", "Ada", Time::now()).await?;
    db.all("select id, name, created_at from users").await
}

Config reads DATABASE_URL from the environment, and varyk run prints 1 Ada and the time the row was added. A Time, a Uuid, and a Bytes each go into a column of their own, and back, with no cast in the query:

Database	`Time`	`Uuid`	`Bytes`
Postgres	`timestamptz`	`uuid`	`bytea`
MySQL	`datetime(6)`	`char(36)`	`blob`
SQLite	`text`	`text`	`blob`

SQLite has no time type, so varyk-sql writes a Time there as text of a fixed width, always with six fraction digits, so that order by and < in SQL put times in the order Varyk does. A Uuid is its 36-character text on MySQL and SQLite, readable in a SQL shell as in JSON. A Postgres time is read from its raw microseconds, so infinity in a column is an Error, not a crash. On Postgres:

// Postgres; SQLite takes `$1` as well as `?`
let id: i64 = db.one("insert into users (name, created_at) values ($1, $2) returning id", name, Time::now()).await?;

Two things a program had to write go. A None on Postgres is now a NULL with no type, which takes its type from where the parameter is first used, so set done = $1 needs no cast; only a parameter first used where nothing gives it a type, as in $1 is null, still needs one. And MySQL's unsigned integers, tinyint, mediumint, and boolean columns read with no cast; under Any, an unsigned value at or above 2^31 in an int unsigned read back as a negative number. A field that refuses a column says so by the column's name, never by its value. The README's column types have the rest.

varyk-http 0.2.0

varyk-http 0.2.0 is on crates.io. Its first service, and its users demo, store created_at as a Time:

async fn create_user(user: NewUser, state: Shared<State>) -> Result<http::Response, Error> {
    if user.name.is_empty() {
        return Err(http::bad_request("a user needs a name"));
    }
    let created_at = Time::now();
    let id: i64 = state.db.one("insert into users (name, created_at) values (?, ?) returning id", user.name, created_at).await?;
    let mut r = http::Response::json(User { id: id, name: user.name.clone(), created_at: created_at });
    r.set_status(201);
    r.set_header("location", format!("/users/{}", id));
    Ok(r)
}

with created_at: Time on User and created_at text not null in the migration. Every read gives the time back:

curl -i -H 'x-api-key: dev-key' -d '{"name":"Ada"}' 127.0.0.1:3000/users
# 201, location: /users/1,
# {"id":1,"name":"Ada","created_at":"2026-10-07T12:00:00.123456Z"}
curl -H 'x-api-key: dev-key' 127.0.0.1:3000/users/1
# {"id":1,"name":"Ada","created_at":"2026-10-07T12:00:00.123456Z"}
curl -H 'x-api-key: dev-key' 127.0.0.1:3000/users/2   # 404 {"error":"not found"}
curl 127.0.0.1:3000/users                             # 401
curl 127.0.0.1:3000/health                            # "ok"

Times and ids in routes. A path or query parameter may be a Time or a Uuid, and a query parameter an Option of one. A Time reads as Time::from_iso reads it, and a Uuid in its 36-character form; anything else is a 400 naming the parameter. In a query string a + reads as a space, as forms encode it, so an offset is sent as %2B: ?since=2026-10-07T12:00:00%2B02:00.

Bytes in and out. Each bytes call has a name of its own, beside the text call it matches, since Varyk has no overloading and the server's Response is also what the client gives back:

Call	Gives
`req.body_bytes()`	the request body as it came, with no copy
`http::Response::bytes(b, content_type)`	a 200 with the body `b`, that `content-type`, and `x-content-type-options: nosniff`
`r.body_bytes()`	a response's body with no UTF-8 check, in a test or from the client
`part.bytes().await`, `part.content_type()`	an uploaded part's content as it came, and the content type the client declared, not checked
`ws.recv_message().await`, `ws.send_bytes(b).await`	WebSocket messages, text or binary
`client.post_bytes(url, b, content_type)`, `client.put_bytes(url, b, content_type)`	a request with `b` as its body
`req.set_body_bytes(b)`	a body of bytes, for a request sent with `app.request` in a test

A content type is always written, so no binary body goes out without a declared type. A Bytes given to the JSON calls, or returned by a handler, is sent as a JSON string of base64, as any value is. ws.recv() stays text, and still closes the connection on a binary message; a handler that takes binary messages asks for them by name:

async fn echo(ws: http::WebSocket) -> Result<http::Response, Error> {
    while let Some(message) = ws.recv_message().await? {
        match message {
            http::live::Message::Text(text) => ws.send(text).await?,
            http::live::Message::Binary(b) => ws.send_bytes(b).await?,
        };
    }
    Ok(http::Response::empty())
}

The README's live connections and uploads section has the rest.

For Rust readers

In the generated Rust the three are ::varyk_std::Time, ::varyk_std::Uuid, and ::varyk_std::Bytes, held by varyk-std on the crates time, uuid, bytes, and base64. Time and Uuid are Copy and passed by value, as numbers are. varyk-std builds every Bytes in the bytes crate's shared form, so the compiler hands a Bytes over as a trailing value by adding one to a reference count, allocating nothing, and axum's request body reaches req.body_bytes() without a copy. The compiler still inserts exactly two allocations, a string literal placed into an owned slot and a string passed as a trailing value, and --emit-rust shows both.

What is not yet

From the language: a calendar date, a time of day, a duration type, time zones and local time, formatting a Time by a pattern, and a monotonic clock; ordering Uuids, the nil id, and other versions; indexing, slicing, or building Bytes piece by piece, and Bytes from a Vec<u8>; Bytes in env::parse; Time or Bytes as a map key; and a handler parameter bound to the raw body. From varyk-sql: numeric, json, date, time of day, interval, and array columns without a cast, a Uuid written as 16 bytes, and session time zones other than UTC. From varyk-http: a bytes body sent in pieces, a patch with a bytes body, and checking a part's declared content type against its content. The reference lists the language's cuts, and the open questions, such as whether Varyk should have a Date or a Duration, are in the compiler's open-questions.md.

Upgrading

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.8.0, and two things in it are breaking. Time, Uuid, and Bytes are now reserved names, as Error is: a program that declares a type, an enum, or a module by one of them renames it, and varyk check reports V0113 until it does. And varyk_std::Value, the type of the values after a facade's other arguments, has three new variants, so a .rs facade that matches on a Value needs arms for them. After cargo install varyk --locked, run varyk check in a package, and it says what to change: the varyk-std line in Cargo.toml, or cargo update -p varyk-std.

A program that uses varyk-sql or varyk-http moves to their new releases at the same time: in Cargo.toml, change the version on the http line to "0.2.0" and on the sql line to "0.3.0". Running varyk add http sql again does not do it, since cargo add keeps the version of a dependency the manifest already lists. Until then, varyk check reports V0404, since varyk-sql 0.2 and varyk-http 0.1 need varyk-std 0.7. varyk-sql's calls are unchanged, and most of the casts 0.2 asked for are no longer needed.

varyk	varyk-sql	varyk-http
0.8	0.3	0.2
0.7	0.2	0.1

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk --locked
varyk init hello
cd hello
varyk run

The getting started page goes from there to a first service on HTTP and a database, and the language reference describes everything the compiler accepts. The READMEs of varyk-http and varyk-sql are the full documentation of the packages.

What is next

Milestone 6 of the roadmap: tooling and beyond, varyk fmt, a language server, nested modules in .rs files, Rust tuple and unit structs imported from .rs files, Debug on imported Rust structs, and a decision on a native backend. Beside it, as their own work, varyk-mongo and varyk-redis, the next packages, and an agent evaluation: the examples written by a model from the language reference alone, with pass rates published, before any page claims that agents write Varyk well. Nothing there is a date.

Varyk is experimental and pre-1.0. Store a time, an id, or an upload with it, and tell us where it hurts: the issues are the place.

varyk-http 0.1.0: HTTP for Varyk

2026-10-06T14:00:00+02:00

varyk-http 0.1.0 is on crates.io. It is the official Varyk package for HTTP: a server on axum and tower-http, and a client on reqwest. It covers what an ordinary production API needs and nothing more: routes the compiler checks, hooks, safe defaults, errors that never leak, WebSockets, server-sent events, uploads, a client, metrics, and tests without a port. It lives in its own repository, and its README is the full documentation.

varyk-http ships with Varyk 0.7.0 because it needs that release's compiler side: the compiler knows this one package by name, checks every route against its handler, and writes the small adapter that calls the package for each route. The package is a .rs facade over axum, tower-http, and reqwest, with its error constructors and its tests written in Varyk; the generated program never names axum, and the first service below writes no Rust. varyk-http 0.1 works with Varyk 0.7, and each minor Varyk release is followed by a varyk-http release, since a program and its packages must resolve to one varyk-std. varyk-sql 0.2.0 ships alongside for the same reason, with nothing else changed.

Adding it

cargo install varyk --version '^0.7' --locked
varyk init users
cd users
varyk add http sql

varyk add http sql adds varyk-http as http and varyk-sql as sql, so code writes http::App and sql::connect. varyk-sql's default driver, SQLite, is compiled from C on the first build, which needs a C compiler; its README has the rest.

A first service

A users API on a database, behind an API key, in one file. src/main.vr:

struct Config {
    database_url: string,
    api_key: string,
    #[default(3000)]
    port: u16,
    #[default("127.0.0.1")]
    address: string,
}

struct User {
    id: i64,
    name: string,
}

struct NewUser {
    name: string,
}

struct State {
    db: sql::Pool,
    api_key: string,
}

async fn list_users(state: Shared<State>) -> Result<Vec<User>, Error> {
    state.db.all("select id, name from users order by id").await
}

async fn get_user(id: i64, state: Shared<State>) -> Result<Option<User>, Error> {
    state.db.first("select id, name from users where id = ?", id).await
}

async fn create_user(user: NewUser, state: Shared<State>) -> Result<http::Response, Error> {
    if user.name.is_empty() {
        return Err(http::bad_request("a user needs a name"));
    }
    let id: i64 = state.db.one("insert into users (name) values (?) returning id", user.name).await?;
    let mut r = http::Response::json(User { id: id, name: user.name.clone() });
    r.set_status(201);
    r.set_header("location", format!("/users/{}", id));
    Ok(r)
}

async fn delete_user(id: i64, state: Shared<State>) -> Result<http::Response, Error> {
    let deleted = state.db.run("delete from users where id = ?", id).await?;
    if deleted == 0 {
        return Err(http::not_found("no such user"));
    }
    Ok(http::Response::empty())
}

async fn health(state: Shared<State>) -> Result<string, Error> {
    let _ok = state.db.run("select 1").await?;
    Ok("ok")
}

async fn check_key(req: http::Request, state: Shared<State>) -> Result<bool, Error> {
    match req.header("x-api-key") {
        Some(key) => Ok(key == state.api_key),
        None => Err(http::unauthorized("an x-api-key header is needed")),
    }
}

async fn open_db(url: string) -> Result<sql::Pool, Error> {
    let db = sql::connect(url).await?;
    db.migrate("migrations").await?;
    Ok(db)
}

fn build_app(state: Shared<State>) -> http::App {
    let mut app = http::App::new(state.clone());
    app.get("/health", health);
    app.get("/users", list_users);
    app.get("/users/{id}", get_user);
    app.post("/users", create_user);
    app.delete("/users/{id}", delete_user);
    app.before_on("/users", check_key);
    app
}

async fn start() -> Result<bool, Error> {
    let config: Config = env::parse()?;
    let db = open_db(config.database_url).await?;
    let mut app = build_app(Shared::new(State { db: db, api_key: config.api_key.clone() }));
    app.set_address(config.address);
    app.serve(config.port).await
}

async fn main() {
    if let Err(e) = start().await {
        log::error("{}", e);
    }
}

migrations/0001_users.sql:

create table users (
    id integer primary key,
    name text not null
);

.env:

DATABASE_URL=sqlite::memory:
API_KEY=dev-key

varyk run serves on 127.0.0.1:3000:

curl -i -H 'x-api-key: dev-key' -d '{"name":"Ada"}' 127.0.0.1:3000/users
# 201, location: /users/1, {"id":1,"name":"Ada"}
curl -H 'x-api-key: dev-key' 127.0.0.1:3000/users/1   # {"id":1,"name":"Ada"}
curl -H 'x-api-key: dev-key' 127.0.0.1:3000/users/2   # 404 {"error":"not found"}
curl 127.0.0.1:3000/users                             # 401
curl 127.0.0.1:3000/health                            # "ok"

The same program, with its tests, is the package's demo/users. A handler is an ordinary async fn. Its parameters are bound by name to the path ({id}) and the query string, and by type to the JSON body, the shared state, and the request; its return value is the response: a value is JSON with 200, None is 404, nothing is 204, and an http::Response is sent as built. varyk check checks every route against its handler before anything builds. A path or query value that does not parse as its type, a missing query value, and a body that is not JSON of its type are each a 400 naming the parameter, and the handler is not called. The Varyk 0.7.0 post and the language reference have the rules.

Safe defaults

The settings are calls on the app before serve:

Call	Default	Meaning
`app.set_address(addr)`	`"127.0.0.1"`	the IP address to listen on; `"0.0.0.0"` in a container
`app.set_body_limit(bytes)`	2 MiB	a larger request body is a 413
`app.set_timeout(ms)`	30 000	a request that takes longer is a 503
`app.set_shutdown_grace(ms)`	30 000	on SIGTERM or ctrl-c, how long requests in flight have to finish
`app.set_idle_timeout(ms)`	75 000	how long a connection may wait for a request's headers, idle between kept-alive requests or still sending them, before it is closed
`app.set_max_in_flight(n)`	none	beyond `n` requests at once, a 503 `{"error":"server busy"}`
`app.allow_origin(origin)`	none	adds one CORS origin; `"*"` allows any
`app.compress()`	off	gzip for responses whose client accepts it
`app.metrics(path)`	off	Prometheus text at `path`

The server listens on 127.0.0.1 until the program sets an address, so a service run on a laptop is not open to its network; serve says so as it starts, listening on http://127.0.0.1:3000 (set_address("0.0.0.0") to accept outside connections). A body limit, a request timeout, and an idle timeout are on without being asked; each bounds one request or connection, not the service as a whole, and the idle timeout means a client that sends its headers slowly or not at all cannot hold connections open. There is no limit on requests in flight unless set_max_in_flight sets one, since memory is the platform's to manage; that limit is load shedding, a 503 beyond a number of requests at once, for a service that wants it. CORS is off until an origin is allowed, and once on it never allows credentials. Compression is off too: compressing a secret beside text an attacker chose leaks it through the length.

A setting with a value that cannot work, a limit of 0 or an address that is not an IP address, makes serve an Err naming the setting, and every app.request a 500, rather than a panic. On SIGTERM or ctrl-c, serve stops accepting, gives requests in flight the shutdown grace, and gives Ok(true).

Nothing internal reaches a client

Call	Status
`http::bad_request(text)`	400
`http::unauthorized(text)`	401
`http::forbidden(text)`	403
`http::not_found(text)`	404
`http::conflict(text)`	409
`http::error(status, text)`	`status`

An Err from a handler or a before hook with a status from 400 to 599 is sent with that status and {"error":"<text>"}: its text is written for the client. Any other error, one passed on with ? from a database call, say, or one with a status outside 400 to 599, is a 500 with the fixed body {"error":"internal error"}, and its message is logged with the method and path. A panic in a handler or a hook is the same fixed 500. So a database message, a file path, or a secret inside an error stays in the log.

The package keeps input out of places it could do harm. Response::file(dir, name) serves a file from a folder and refuses a name that is absolute, has an empty, ., or .. part, has a part starting with ., or leads outside the folder through a link, as a 404, as a missing file is, so a client cannot tell them apart. A header that is not valid HTTP, and a cookie name or value that could add attributes, make the response a 500 with the reason logged. set_cookie writes HttpOnly, Secure, and SameSite=Lax. Log lines carry the path still percent-encoded and without its query string, and a name or message a client chose is written escaped, so it cannot start a log line of its own.

Hooks and auth

async fn check_key(req: http::Request, state: Shared<State>) -> Result<bool, Error> {
    match req.header("x-api-key") {
        Some(key) => Ok(key == state.api_key),
        None => Err(http::unauthorized("an x-api-key header is needed")),
    }
}

async fn stamp(req: http::Request, mut res: http::Response) {
    res.set_header("x-served-by", "users");
}

app.before(f) runs f before every route, app.before_on("/admin", f) before the routes whose path, as the program wrote it, is /admin or starts with /admin/ (not /administrators), and app.after(f) on every response the router makes. Each hook covers every route, wherever its line is, and hooks run in the order they were added. A before hook gives Ok(true) to let the request through, Ok(false) for a 403 {"error":"forbidden"}, or an Err, sent as above. Because before_on tests the route the request matched, no spelling of a path reaches an /admin route without its hook. before hooks run after routing, so a request no route matches is a 404 without running any; a client can therefore tell a route that exists (refused by its hook, 401 or 403) from one that does not (404).

A handler that needs the user calls a function of the program, let user = current_user(req, state)?;. The first service compares its key with ==, which is not constant time; a production check compares in constant time in a facade function of the program or uses bearer tokens. The README has a Rust facade of the program over jsonwebtoken and argon2 for tokens and password hashes, and the Varyk function that gives a refused token its 401. The package checks neither a body's content-type nor a request's Origin: against a cross-site request, the defence is the SameSite=Lax cookie set_cookie writes, and a service that takes cookies some other way checks Origin in a before hook.

WebSockets, server-sent events, and uploads

A handler takes a WebSocket, an event stream, or a multipart form as a parameter, bound by type as the request is. A live handler returns nothing, or Result<http::Response, Error> so that ? works on its calls; the response it returns is ignored, since the connection was already answered, and an Err is logged. The connection closes when the handler returns.

async fn chat(ws: http::WebSocket) -> Result<http::Response, Error> {
    while let Some(text) = ws.recv().await? {
        ws.send(format!("you said: {}", text)).await?;
    }
    Ok(http::Response::empty())
}

with app.get("/chat", chat);. Messages are text, and the package answers pings. A client's fault, a binary message, a malformed one, or one larger than the body limit, closes the connection with its code and makes recv give None.

async fn ticks(events: http::Sse) -> Result<http::Response, Error> {
    let mut i = 0;
    while i < 10 {
        events.send_event("tick", format!("{}", i)).await?;
        time::sleep(1000).await;
        i = i + 1;
    }
    Ok(http::Response::empty())
}

events.send(text) sends one data: event and events.send_event(name, text) one with a name; the package sends a comment every 15 seconds while the handler is quiet, so proxies keep the connection open.

async fn upload_avatar(id: i64, form: http::Multipart) -> Result<http::Response, Error> {
    while let Some(part) = form.next().await? {
        if part.name() == "avatar" {
            let _written = part.save_to("uploads", format!("{}.png", id)).await?;
        }
    }
    Ok(http::Response::empty())
}

with app.post("/users/{id}/avatar", upload_avatar);. Save an upload under a name and extension the program chooses, as here, never under part.file_name(), which is whatever the client sent. save_to refuses a name by the rule of Response::file and writes to a temporary file first, so a failed upload leaves nothing behind. What the handler reads counts against the body limit, and what it leaves unread is never read. Messages and parts are text and files until milestone 5c brings a bytes type.

The client, metrics, and tests

struct Forecast {
    summary: string,
}

struct State {
    client: http::Client,
}

async fn forecast(state: Shared<State>) -> Result<Forecast, Error> {
    let r = state.client.get("https://weather.example/today").await?;
    if r.status() != 200 {
        return Err(http::error(502, "the weather service did not answer"));
    }
    r.read_json()
}

fn weather_client(key: string) -> http::Client {
    let mut client = http::Client::new();
    client.set_header("authorization", key);
    client
}

client.get(url) and client.delete(url), and post, put, and patch with a body sent as JSON, each give Result<http::Response, Error>. A response of any status is Ok; an Err is a response that could not be had, and its message names the scheme and host, never the path or query, which may hold a token. Redirects are followed only to the same scheme, host, and port, so a default header such as an API key never goes to a host the program did not name. The client uses rustls with built-in root certificates, so it works in a minimal container, with a 30-second timeout and a 10 MiB body limit by default. Make one at startup and keep it in the state; client.clone() shares its connections.

app.metrics("/metrics") serves Prometheus text: http_requests_total by method, route, and status, and http_request_duration_seconds, a histogram by method and route. The route label is the route's pattern, /users/{id}, never the path a client sent. The metrics path is open to anyone who can reach the service, so a service that listens beyond 127.0.0.1 keeps it from the public at its proxy.

app.request(req).await runs one request through the same router, settings, and hooks as serve, without a port, under varyk test:

async fn test_app() -> Result<http::App, Error> {
    let db = sql::connect_with("sqlite::memory:", 1).await?;
    db.migrate("migrations").await?;
    Ok(build_app(Shared::new(State { db: db, api_key: "test-key" })))
}

#[test]
async fn creates_a_user() {
    let app = match test_app().await {
        Ok(app) => app,
        Err(e) => {
            assert_eq(e.message(), "no error");
            return;
        }
    };
    let mut req = http::Request::new("POST", "/users");
    req.set_header("x-api-key", "test-key");
    req.set_body("{\"name\":\"Ada\"}");
    let r = app.request(req).await;
    assert_eq(r.status(), 201);
    assert_eq(r.header("location"), Some("/users/1"));
}

Each sqlite::memory: pool is a database of its own, so every test starts empty. An event stream's events are collected whole once its handler returns, so r.body() gives them; a WebSocket route answers a 400, since no request app.request sends is an upgrade. Run varyk test from the package's folder, where migrations and .env are.

In production

Configuration. The port, the address, and secrets come from the environment with env::parse, as the first service does: in development from .env, which varyk init keeps out of git.
Containers. In a container the service listens on 0.0.0.0: the first service reads ADDRESS and calls set_address with it. The README has a Dockerfile that builds with varyk build --release on Debian 12 and copies the executable and migrations/ into a distroless image with ADDRESS=0.0.0.0. On SIGTERM the service gives requests in flight the shutdown grace.
Idle connections. The service closes a connection that has sent no request for 75 seconds, so a load balancer or proxy in front must close its idle connections sooner, or an occasional request fails with a 502. AWS's Application Load Balancer and nginx's upstream keep-alive default to 60 seconds, which is sooner; behind Google Cloud's Application Load Balancers, which keep idle connections for 600 seconds, set app.set_idle_timeout(620000);.
TLS is the proxy's or the load balancer's: the package serves plain HTTP/1.1. So are security headers and rate limiting per client.
Health. A get("/health", health) route whose handler runs db.run("select 1"), outside any before_on prefix, so the platform needs no key.
Logging. One line per request after its response, GET /users/1 200 3ms, a 500's message at error level, and startup and shutdown at info level, through Varyk's log, which a program with an http::App starts by itself.

What is not in it

HTTP/2 and TLS in the server, which are the proxy's; binary WebSocket messages and bytes bodies, until milestone 5c brings a bytes type; streaming request and response bodies beyond Response::file and save_to; per-request client headers and a request builder; client cookies and proxies (the client ignores HTTP_PROXY and always connects directly); route groups and a wrapping hook; OpenTelemetry; rate limiting per client; serving a whole folder of static files; and templates.

What is next

Milestone 5c of the roadmap: a date-time type, a UUID type, and a bytes type, which lets varyk-http read uploads and binary bodies, so the users API does not send a date as a string. Milestone 5's bar, a users API on a database that is varyk init, varyk add http sql, one file, and varyk run away, is met when 5b4 and 5c are done. After 5b4, varyk-mongo and varyk-redis are the next packages. Nothing there is a date.

Varyk and varyk-http are experimental and pre-1.0. Put a small service behind it and tell us where it hurts: the issues are the place.

Varyk 0.7.0: routes the compiler checks

2026-10-06T12:00:00+02:00

Varyk 0.7.0 is on crates.io. It is milestone 5b4 of the roadmap, the fifth part of the batteries for services. Milestone 5b3 gave a package's .rs facade what the database package varyk-sql needs. Milestone 5b4 does the same for HTTP: a handler is an ordinary async fn, a route names it, and varyk check checks the route against the handler's parameters before anything is built. With it, a users API on a database is varyk init, varyk add http sql, one file, and varyk run away.

The HTTP package itself, varyk-http, lives in its own repository and is released on its own; its first release, varyk-http 0.1.0, ships with this one, and has the server's settings, the client, WebSockets, and the rest. This release is the compiler side. varyk-sql 0.2.0 ships with it too: it moves to varyk-std 0.7, with nothing else changed, because a program and its packages share one varyk-std.

Why the compiler knows one package

Varyk has no function values, so a route table cannot be an ordinary call that takes a function: some part of it must be known to the compiler. A general mechanism, a facade parameter that takes a function, would need the same knowledge and a mechanism nothing else uses; attributes on handlers would scatter the route table across the program. So the compiler knows varyk-http by its crate name, as it knows varyk-std. When a build holds that package, under whatever key, the calls that add routes and hooks to its App are the compiler's own, and every other call on the app is an ordinary call of an imported struct. A package nobody designed with the compiler can still offer a plain function through the facade shapes every package has.

What is in it

Routes and handlers. This is the language reference's example, after varyk add http:

struct User {
    id: i64,
    name: string,
}

struct NewUser {
    name: string,
}

struct State {
    users: Vec<User>,
}

async fn get_user(id: i64, state: Shared<State>) -> Option<User> {
    for user in state.users {
        if user.id == id {
            return Some(user.clone());
        }
    }
    None
}

async fn create_user(user: NewUser, state: Shared<State>) -> Result<http::Response, Error> {
    if user.name.is_empty() {
        return Err(http::bad_request("a user needs a name"));
    }
    let created = User { id: state.users.len() as i64 + 1, name: user.name.clone() };
    let mut r = http::Response::json(created);
    r.set_status(201);
    Ok(r)
}

fn build_app(state: Shared<State>) -> http::App {
    let mut app = http::App::new(state.clone());
    app.get("/users/{id}", get_user);
    app.post("/users", create_user);
    app
}

and in async fn main():

let users = vec![User { id: 1, name: "Ada" }];
let app = build_app(Shared::new(State { users: users }));
let port: u16 = 3000;
if let Err(e) = app.serve(port).await {
    log::error("cannot serve: {}", e);
}

GET /users/1 is answered with a 200 and {"id":1,"name":"Ada"}, GET /users/2 with a 404, and GET /users/abc with a 400 saying that the path parameter id cannot be read from abc; get_user is not called for abc. POST /users with {"name": "Bo"} is answered with a 201.

A route is get, post, put, patch, or delete, with a path written in quotes, whose parts are either written out or a name in braces, {id}. Each parameter of the handler gets its value from the request by the first rule that fits: a parameter named after a {name} of the path is that part of the path; a Shared of the app's state is the state; an http::Request is the request itself, to read headers, cookies, or the body; on post, put, and patch, one parameter of a type JSON can hold is the body; and any other integer, bool, string, or Option of one is read by its name from the query string, so search(prefix: Option<string>, exact: bool) reads /search?prefix=A&exact=true.

Anything that fits no rule is an error at the route, one per problem: a {name} with no parameter, a body on get, two states, a parameter that gets no value from the request. So renaming a parameter cannot quietly stop it from getting its value. The request is read before the handler runs: a value that is not of its type, a missing query value, or a body that is not JSON of its type is a 400 naming the parameter, and the handler is not called, so inside a handler every parameter is a real value of its type.

Responses. What a handler returns is its answer: nothing is a 204, a value JSON can write a 200 with the value as JSON, an Option a 200 or, for None, a 404, and an http::Response is sent as built, for another status, a header, or plain text. A Result of one of these with Error gives the value's answer for Ok and the error's for Err.

Hooks. app.before(f) runs f before every request a route matches, app.before_on(prefix, f) before the routes under a prefix, and app.after(f) on every response the router makes. A before hook gives Ok(true) to let the request through, Ok(false) for a 403, or an Err; an after hook changes the response through a mut parameter:

async fn check_key(req: http::Request, state: Shared<State>) -> Result<bool, Error> {
    match req.header("x-key") {
        Some(key) => Ok(key == state.key),
        None => Err(http::unauthorized("an `x-key` header is needed")),
    }
}

async fn stamp(req: http::Request, mut res: http::Response) {
    res.set_header("x-served-by", "users");
}

These run with app.before_on("/admin", check_key); and app.after(stamp); in build_app, for a State with a key field. before_on is matched against the path of the route the request matched, as the program wrote it, on whole parts: "/admin" covers /admin/users/{id}, not /administrators, and no spelling of a request's path skips it. Each hook covers every route of the app, wherever its line is. A handler that needs to know who is asking calls a function of the program, let user = current_user(req, state)?;; a hook hands it nothing.

Requests in a test. app.request(req).await sends one request through the app, hooks included, without a port, and gives the response the server would have sent:

#[test]
async fn gets_a_user() {
    let users = vec![User { id: 1, name: "Ada" }];
    let app = build_app(Shared::new(State { users: users }));
    let r = app.request(http::Request::new("GET", "/users/1")).await;
    assert_eq(r.status(), 200);
    assert_eq(r.body(), "{\"id\":1,\"name\":\"Ada\"}");
}

build_app is the function main uses too, so a test sends its requests to the same app the service serves. A program that makes an app starts logging in main and in every async test, so the message of a 500 is on the screen under varyk test too.

Error with a status. Error gains an optional HTTP status. Error::with_status(status, text) makes one from Varyk, and e.status() reads it, an Option<u16>. varyk-http's constructors are Varyk functions over it: http::bad_request(text) (400), http::unauthorized(text) (401), http::forbidden(text) (403), http::not_found(text) (404), http::conflict(text) (409), and http::error(status, text) for any other.

How an error is sent is fixed by the compiler's design, because it is the rule that keeps a service's internals from its clients. An error with a status from 400 to 599 is sent with that status and the body {"error":"<message>"}. Any other error, one made by Error::new or passed on with ? from a database query, or one with a status outside 400 to 599, is a 500 with the fixed body {"error":"internal error"}, and its message is logged with the request's method and path. A status therefore means the message was written for the client, and only Varyk code sets one: no official package's Rust does. A database message, a file path, or an address inside an error stays in the log.

Two facade shapes. A .rs facade function may take a value JSON can write, as &T with T: serde::Serialize + ?Sized (or varyk_std::serde::Serialize + ?Sized), the half of the type parameter that milestone 5b3 left for this one. At a call it takes any type json::stringify writes, with the same checks, and the value is read, not given away. varyk-http's Response::json(value) and its client's post(url, body) take their values this way. The reference's in-memory store gains a method of this shape:

pub fn save<T: varyk_std::serde::Serialize + ?Sized>(
    &mut self,
    key: &'static str,
    value: &T,
) -> Result<u64, varyk_std::Error> {
    // stores `value` under `key` with `serde_json::to_value`
}

which Varyk code calls with a struct the facade has never seen, db.save("user/2", bo)?;, and bo stays usable after the call. A facade may also return a bare varyk_std::Error, for a function that makes an error of its own.

varyk add http sql. varyk add http runs cargo add varyk-http --rename http, so code writes http::App, as varyk add sql does for the database. Name several and each runs its own cargo add, in order, stopping at the first failure; the full crate names work too (varyk add varyk-http varyk-sql). That form takes no other argument; with one official name, any later arguments go to cargo as written (varyk add sql --features postgres). A short name with --rename is refused, since http and sql are also names of unrelated crates: write the full name, varyk add varyk-http --rename web.

New diagnostic codes. V0219 is a route whose path and handler do not fit. V0220 is a handler or hook of the wrong shape: not an async function of the package, a return type outside the list, a hook's parameters out of order. V0221 is a route or hook added to an app that is not a local made with http::App::new in the same function, inside a loop, or an assignment to a name holding an app. V0222 is a path or prefix that is not valid, or a method and path already taken. V0407 is a varyk-http that does not match this compiler. Others gain a case: V0901 names a route whose handler, or an app whose state, holds a Rust value that cannot go to another thread, and V0214 a route or hook that leads back to the function adding it. The reference has the new HTTP section, and the error codes the full table.

There is no new example program in the compiler's examples/ this time. Its test suite proves the routes with a stub varyk-http, an in-memory router with no network, and a program that uses it; the real package's own tests and its users demo run on axum.

For Rust readers

For each route the compiler writes one small function with concrete types, in the module of the route call. This is the one it writes for app.get("/users/{id}", get_user), from the users API at the top of the home page, as it is in the generated src/main.rs:

#[allow(warnings, arithmetic_overflow, unconditional_panic)]
async fn varyk_route_0(varyk_req: ::http::Request) -> ::http::Response {
    let varyk_0 = match varyk_req.param::<i64>("id") {
        Ok(v) => v,
        Err(r) => return r,
    };
    let varyk_1 = match varyk_req.state::<State>() {
        Ok(v) => v,
        Err(r) => return r,
    };
    match get_user(varyk_0, &varyk_1).await {
        Ok(v) => ::http::respond_option(v),
        Err(e) => ::http::respond_error(e),
    }
}

and the route becomes app.get("/users/{id}", ::http::route(varyk_route_0));. The program names only the package's items, never axum, so axum's Handler trait and its errors never reach a writer; --emit-rust shows every adapter, and a rustc error inside one is reported at its route.

What is not yet

From HTTP: a hook that wraps the handler and calls it itself; groups of routes as values; a handler reading a header or cookie by name without taking http::Request; a body read as anything but JSON or a multipart upload; headers for one client request beyond the client's defaults; adding a route to an app a function was given rather than one it made; a handler that is a method, a function of a .rs file, or a function of another package; TLS in the server, which is the job of the proxy in front of it; request and response bodies sent in pieces; an OpenAPI document written from the routes; and types for dates, times, UUIDs, and bytes, which come in milestone 5c. From facades: two type parameters, both kinds at once, a where clause, or another bound, and varyk_std::Error in a parameter or a field. The reference lists them all.

Upgrading

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.7.0; varyk-std's Error gains its status. Nothing in 0.7.0 breaks an existing Varyk program; before 1.0, a new feature bumps the minor version, as a breaking change does. After cargo install varyk, run varyk check in a package, and it says what to change: the varyk-std line in Cargo.toml, or cargo update -p varyk-std.

A program that uses varyk-sql moves to varyk-sql 0.2 at the same time: run varyk add sql again, which rewrites the sql line to varyk-sql 0.2.0. Until it does, varyk check reports V0404 at varyk-sql 0.1's own manifest, not at the program's. The two releases differ only in the varyk-std they need: a program and its packages resolve to one varyk-std, so varyk-sql 0.2 works with Varyk 0.7, and varyk-sql 0.1 stays with Varyk 0.6. varyk-sql's README has the table.

Varyk 0.7.1, on 7 October, is a patch release: varyk init also writes a .dockerignore with target and .env, so a container build copies neither, and V0219's note for a path parameter of the wrong type names the types that fit. Nothing else changed. After cargo install varyk --locked, varyk check in a package made with 0.7.0 asks for cargo update -p varyk-std.

Varyk 0.7.2, the same day, is another patch release from the same walkthrough. main may return a Result of something and Error: ? then works in it, and an Err is logged, or printed on stderr in a program that does not log, and the program exits with code 1, so a service that cannot start says so to whatever runs it. A main that returns nothing works as before. A Result used where its value is wanted now suggests ?; http:: or sql:: used before varyk add http sql says how to add the package; and text that is not JSON at all, such as a form sent where a JSON body is expected, is reported as "it is not JSON".

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts. For a service, varyk add http sql and the varyk-http post take it from there.

What is next

First, varyk-http 0.1.0, which ships with this release and has its own post: the server on axum with safe defaults, the client, WebSockets, server-sent events, uploads, metrics, and the users API as its demo.

Then milestone 5c, time, ids, and bytes: a date-time type, a UUID type, and a bytes type, so the users API does not send a date as a string, and varyk-http can read binary bodies. Milestone 5's bar, the golden path, is met when 5b4 and 5c are done. Beside them, as its own work, an agent evaluation: the examples written by a model from the language reference alone, with pass rates published, before any page claims that agents write Varyk well. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Write a small service with it and tell us where it hurts: the issues are the place.

varyk-sql 0.1.0: SQL databases for Varyk

2026-10-04T14:00:00+02:00

varyk-sql 0.1.0 is on crates.io. It is the official Varyk package for SQL databases: SQLite, Postgres, and MySQL through sqlx. It covers what an ordinary service does with a database and nothing more: connect, over TLS when the URL asks for it, run migrations, query, write inside transactions, log, and test against an in-memory SQLite database. It lives in its own repository, and its README is the full documentation.

varyk-sql ships with Varyk 0.6.0 because it needs that release's facade features. The package is a .rs facade over sqlx, with its tests written in Varyk: a query call reads its rows into whatever struct the caller names, takes the query's values after the text, and takes the text itself only as written in the program. A program that uses it writes no Rust. varyk-sql 0.1 works with Varyk 0.6, and each minor Varyk release is followed by a varyk-sql release, since a program and the package must resolve to one varyk-std.

Adding it

cargo install varyk
varyk init users
cd users
varyk add sql

varyk add sql runs cargo add varyk-sql --rename sql, so code names the package sql::. The default driver is SQLite, compiled from its C source on the first build: that needs a C compiler (Xcode's command-line tools on macOS, build-essential on Debian and Ubuntu) and takes a few minutes, once. A server driver is a feature:

varyk add sql --features postgres                        # Postgres, and SQLite for tests
varyk add sql --no-default-features --features postgres  # Postgres only, skips the SQLite build
varyk add sql --features mysql                           # MySQL, and SQLite for tests

A first service

src/main.vr:

struct Config {
    database_url: string,
}

struct User {
    id: i64,
    name: string,
}

async fn load() -> Result<Vec<User>, Error> {
    let config: Config = env::parse()?;
    let db = sql::connect(config.database_url).await?;
    db.migrate("migrations").await?;
    db.run("insert into users (name) values (?)", "Ada").await?;
    db.all("select id, name from users").await
}

async fn main() {
    match load().await {
        Ok(users) => {
            for user in users {
                println!("{} {}", user.id, user.name);
            }
        }
        Err(e) => log::error("{}", e.message()),
    }
}

migrations/0001_users.sql:

create table users (
    id integer primary key,
    name text not null
);

.env:

DATABASE_URL=sqlite::memory:

varyk run prints 1 Ada. main returns nothing in Varyk, so the work is in load, and main matches on its result; all takes its row type from load's return type. The URL's scheme picks the driver. On Postgres the query writes $1 for ?, and the migration differs: integer primary key numbers new rows by itself only on SQLite; on Postgres the column is id integer primary key generated always as identity, and on MySQL id integer primary key auto_increment (see the README).

The calls

sql::connect(url) gives a pool of up to 10 connections, which waits up to 30 s for a free one; sql::connect_with(url, max_connections) sets the count. db.clone() is another handle to the same pool, for a started task that needs one.
On a pool and on a transaction, one gives the first row as a T or an Error when there is none, first the first row or None, all every row, and run runs a statement and gives the number of rows it changed. T comes from where the result goes, and a struct is read by column name, a field's #[rename("..")] included.
db.begin() starts a transaction on one connection of the pool, and commit commits it. A transaction dropped without commit rolls back, so an early return or a ? undoes it; there is no rollback call and no nested transaction.
db.migrate("migrations") applies, in order, every .sql file in the folder (not .down.sql) not yet recorded in the database's _sqlx_migrations table. The files use sqlx's format, so the same folder works with sqlx's own CLI.

async fn rename(db: sql::Pool, id: i64, name: string) -> Result<bool, Error> {
    let mut tx = db.begin().await?;
    let changed = tx.run("update users set name = ? where id = ?", name, id).await?;
    if changed != 1 {
        return Err(Error::new("no such user"));
    }
    tx.run("insert into audit (user_id, action) values (?, 'rename')", id).await?;
    tx.commit().await
}

Why the query is literal

The query is literal text: a query built from input does not compile. The package's guard against SQL injection is a compiler check: the query parameter of one, first, all, and run is a &'static str, which Varyk 0.6.0 lets take only text written in the program, and a name or a format! there is V0217, checked at the program's call site. The values go after the text, one per placeholder: bool, string, floats, integers up to i64, and an Option of each, where None is NULL.

let user: Option<User> = db.first("select id, name from users where id = ?", id).await?;

The placeholders are the database's own, passed through: ? on SQLite and MySQL, $1, $2 on Postgres. A program that runs on two databases keeps two queries. On SQLite and MySQL the number of values is checked against the number of placeholders before the query runs, and a mismatch is an Error naming both, because SQLite would otherwise bind a missing value as NULL and ignore an extra one. On Postgres the server rejects too few values and ignores an extra one.

When something goes wrong

Every failure is an Error whose message the package writes, and no call panics.

A failed statement ends its transaction. When a statement in a transaction fails in the database, with a duplicate key, a deadlock, or a missing table, the transaction is over: every later query on it is an Error, "a statement in this transaction failed; it will roll back", without reaching the database, and commit rolls it back and is an Error, "the transaction was rolled back: a statement in it failed". To try again, start a new transaction. The rule is the same on all three databases, because each would otherwise behave differently: Postgres aborts the transaction at the failure, and a MySQL deadlock and some SQLite errors end it on the server. An Error from reading the rows into T does not end the transaction, nor does the package's own count of values on SQLite and MySQL; on Postgres too few values is a database error and does.

An error on a later row is an error. one and first add no limit. On Postgres and MySQL both read the rest of the result and drop it, so a statement that fails on a later row is an Error, not the first row, and the connection's next statement is not handed that error.

A failed migration lets go. On Postgres and MySQL sqlx takes a lock while it applies migrations, so replicas starting together apply each one once. A failed migration is an Error naming its version and the database's message, and it releases the lock, so another replica's migrate does not wait on it.

Errors carry no secrets they can avoid. A connection failure says which step failed and never contains the URL, so a password cannot reach a log that way. A database error keeps the database's own message, which names the constraint or column where there is one, and never includes Postgres's "detail" field, which can hold the row's values. Postgres and MySQL may still quote the offending value in the message itself, a duplicate key for example, so treat these messages as data: log them, and give clients a message of your own.

Columns and ids

sqlx's Any driver, which serves all three databases through one pool, reads booleans, integers, floats, and text; anything else is cast in the query, such as id::text for a Postgres uuid or timestamptz, and cast(x as char) for a MySQL datetime. Every selected column must be one the driver reads, whether or not T has a field for it, so name the columns instead of select *. The README has the table for each database.

One case reads wrong without an Error: the driver reads MySQL's smallint unsigned, int unsigned, and bigint unsigned as signed, so a large value wraps to a negative number. Read a smallint unsigned or an int unsigned with cast(x as signed) into an i64, and a bigint unsigned that may reach 2^63 with cast(x as char) into a string.

Each call on a pool may run on a different connection, so a new row's id is read in the statement that makes it, with returning on Postgres and SQLite:

// Postgres ($1) and SQLite (?)
let id: i64 = db.one("insert into users (name) values ($1) returning id", name).await?;

MySQL has no returning, and select last_insert_id() on a pool may run on another connection than the insert, so both go in one transaction, which holds one connection:

let mut tx = db.begin().await?;
let _added = tx.run("insert into users (name) values (?)", name).await?;
let id: i64 = tx.one("select last_insert_id()").await?;
tx.commit().await?;

Testing

async fn count_users() -> Result<i64, Error> {
    let db = sql::connect_with("sqlite::memory:", 1).await?;
    db.migrate("migrations").await?;
    db.run("insert into users (name) values (?)", "Ada").await?;
    db.one("select count(*) from users").await
}

#[test]
async fn adds_a_user() {
    let counted: Result<i64, Error> = count_users().await;
    match counted {
        Ok(n) => assert_eq(n, 1),
        Err(e) => assert_eq(e.message(), "no error"),
    }
}

Each sqlite::memory: pool is a database of its own, alive while the pool is, so every test starts empty. It is a pool of one connection whatever the count, which keeps the test's queries in order; a query on the pool while a transaction is open waits for that connection and fails after 30 s, so finish the transaction first. Run varyk test from the package root, since migrate("migrations") and .env are read relative to the working directory.

In production

TLS. sqlx is built with rustls and the webpki root certificates, so TLS works in a minimal container with no CA bundle and no OpenSSL. The URL asks for it: ?sslmode=verify-full on Postgres and ?ssl-mode=VERIFY_IDENTITY on MySQL check the certificate and host name; require and REQUIRED encrypt but accept any certificate.
Migrations. Call db.migrate("migrations") at startup, or apply the folder from CI with sqlx migrate run. The folder is a path relative to the working directory, so the container holds it beside the executable; the README has a Dockerfile that builds with varyk build --release and copies migrations/ into a distroless image.
Logging. sqlx reports each statement at debug level through tracing, which a Varyk program that logs already sets up: the SQL text and the time it took, never the values. LOG=debug turns these lines on.
Health. db.run("select 1") is the readiness check: it takes a connection from the pool and asks the database for an answer.

What is not in it

Pool options beyond max_connections (timeouts, idle, lifetime); rollback as a call, and savepoints; streaming rows; embedding the migration files in the executable; down migrations; date, uuid, bytes, numeric, JSON, and array columns without a cast; a query spanning two databases' placeholder styles; sqlx's compile-time checked query!; Postgres listen and notify, and copy; a Shared pool for HTTP handlers, which comes with milestone 5b4; and MongoDB and Redis, which are their own packages, after 5b4.

What is next

Milestone 5b4 of the roadmap is varyk-http and the golden path: an HTTP server with an explicit route table, a handler's parameters bound by name to the route and by type to shared state, an HTTP client, and the bar for all of milestone 5, a users API on a database that is varyk init, varyk add http sql, one file, and varyk run away. Nothing there is a date.

Varyk and varyk-sql are experimental and pre-1.0. Point a small service at your database and tell us where it hurts: the issues are the place.

Varyk 0.6.0: facades for packages

2026-10-04T12:00:00+02:00

Varyk 0.6.0 is on crates.io. It is milestone 5b3 of the roadmap, the fourth part of the batteries for services. Milestone 5b2 let a Varyk package use another Varyk package by name, and moved the database and HTTP to packages, varyk-sql and varyk-http. Milestone 5b3 is what such a package needs from the compiler: a .rs facade that can say "read the result into whatever type you name" and "take these values, however many", so that varyk-sql can keep its Rust in a facade, and a program that uses it writes no Rust at all. It also gives a facade a parameter that takes only text written in the program, which is what will make a database query built from input a compile error.

varyk-sql itself lives in its own repository and is released on its own; its first release, varyk-sql 0.1.0, ships with this one. This release is the compiler side.

Why facades

A facade is the .rs file in a package through which Varyk code reaches a Rust crate. Until now it could name only concrete types, so a package could not offer "read this row into whatever struct you name", or "take these values, however many": the two things a database package is made of. Milestone 5b3 adds four shapes a facade can declare, one thing a .vr file can say, and one convenience for adding a package. Apart from pub use, none of it is new Varyk syntax: a Varyk function still has no type parameters, no variadic parameter, and no literal-only parameter. These are shapes the compiler accepts in a .rs signature, and rules for calling them.

What is in it

A type taken from where the result goes. A pub fn or method of a .rs module may have one type parameter, T: serde::de::DeserializeOwned, or varyk_std::serde::de::DeserializeOwned, which needs no serde dependency, and return Result<T, varyk_std::Error>, Result<Option<T>, varyk_std::Error>, or Result<Vec<T>, varyk_std::Error>. At a call, T is the type the result is used as, found as for json::parse: a let with a written type, an argument, a return value, or a field, through ? and .await. T is any type json::parse reads, with the same attribute checks (V0209), so the facade reads into a struct it has never seen. With nothing to say the type, or for a started call, which has no .await, it is V0207, and a Rust type from a .rs module or a type of another package is V0210. The generated Rust writes T after the name.

Any number of values. The last parameter of a facade function may be Vec<varyk_std::Value>, which Varyk code writes as zero or more arguments after the others. Each is a bool, string, f32, f64, i8 to i64, u8 to u32, or an Option of one of those; anything else is V0218, and for a u64 or usize the help writes as i64. Value holds scalars only, built by the compiler without serde, so no conversion can fail: a design that sent any data type through serde was considered and dropped, because its only ways to handle a failed conversion were a crash, an error on every call, or a silent Null, which in a database query is wrong data with no error. Each value is read, not given away, so a name passed stays usable after the call.

Text written in the program. A parameter of type &'static str takes only a string literal, escapes included, and nothing else. A name, a parameter, or a format! there is V0217, "this argument must be text written in the program", and for a format! a note says to pass the values after the text instead. The compiler knows nothing about SQL; it knows that this parameter takes only a literal. The check happens at the program's call site, where its input is visible to the compiler, so in varyk-sql no input can become part of a query: the values go after the text, and the database binds them.

Varyk's own Error. A facade may return varyk_std::Error, by that full path, as the error of a returned Result. Varyk sees it as its own Error, so ? opens it in a function returning Result<_, Error>, and match reads e.message().

pub use. A .vr file may re-export a function, struct, or enum of its own package, so a library's root can gather what its users need:

// src/lib.vr of a package `shelf`
pub mod store;

pub use store::item;
pub use store::Book;

A program that uses shelf writes shelf::item(3) and shelf::Book, and may still write shelf::store::item(3). The item must be pub, and so must every module on its own path from the root, so the types it names stay visible to its users.

varyk add sql. varyk add gains a shorthand for the official database package: varyk add sql runs cargo add varyk-sql --rename sql, so code writes sql::connect, and any later arguments go to cargo as written (varyk add sql --features postgres). One shorthand per call. A call whose first argument is not a shorthand is passed through unchanged, as before. varyk add sql works with varyk-sql 0.1.0, released with it.

A second allocation, named. Until now the compiler inserted exactly one kind of allocation: a string literal placed into an owned slot. A string passed as a trailing value is the second: the function receiving the values owns them, so Value::from copies the text as it hands the value over, the cost of sending it out. --emit-rust shows both, and nothing else copies a string's text behind your back.

New diagnostic codes. V0217 is an argument to a literal-text parameter that is not a string literal. V0218 is a trailing value of a type that cannot be passed as a value. The language reference has the new section, and the error codes the full table.

There is no new example program this time. The compiler's own test suite proves the facade shapes with a package whose facade is an in-memory store shaped like varyk-sql's, and a program that uses it.

A facade, worked through

This is the reference's example: a facade shaped like varyk-sql's, with a map in memory in place of a database. The facade is Rust; the reference leaves out the bodies of its two methods, as here:

// src/kv.rs of a package `store`, with `serde_json` and `varyk-std` in
// its [dependencies]
pub struct Store {
    entries: std::collections::BTreeMap<String, serde_json::Value>,
}

pub fn open() -> Store {
    Store { entries: std::collections::BTreeMap::new() }
}

impl Store {
    pub fn put(
        &mut self,
        key: &'static str,
        values: Vec<varyk_std::Value>,
    ) -> Result<u64, varyk_std::Error> {
        // turns `values` into JSON and stores it under `key`
    }

    pub fn one<T: varyk_std::serde::de::DeserializeOwned>(
        &self,
        key: &'static str,
        values: Vec<varyk_std::Value>,
    ) -> Result<T, varyk_std::Error> {
        // reads the JSON under `key` with `serde_json::from_value`
    }
}

The package's root gives the program short names:

// src/lib.vr of `store`
pub mod kv;

pub use kv::open;
pub use kv::Store;

and the program writes no Rust:

// in a program with `store = { path = "../store" }` and `varyk-std` in
// its [dependencies]
struct User {
    id: i64,
    name: string,
}

fn add_ada() -> Result<User, Error> {
    let mut db = store::open();
    let name = "Ada";
    db.put("user/1", 1, name)?;
    db.one("user/1")
}

add_ada stores [1, "Ada"] and reads it back as a User. "user/1" is text written in the program; 1, name are the values after it, read and not given away; User comes from the return type; and ? works because the facade returns Varyk's own Error. For Rust readers, the last call is written ::store::kv::Store::one::<User>(&db, "user/1", vec![]).

What is not yet

A type parameter in a parameter (&T: Serialize, for sending a Varyk value out, planned for 5b4), two type parameters, a where clause, or another bound; a u64, a struct, a Vec, or a map as a trailing value. Also not yet: varyk_std::Error anywhere but as the error of a returned Result; a Varyk function with a literal-only parameter or one taking any number of values, so a .vr wrapper cannot pass a query through, and varyk-sql puts every call that takes a query in its .rs facade; naming varyk_std::Value from Varyk code; pub use of a module, with braces, globs, or as, or of an item of another package; and several shorthands in one varyk add. The reference lists them.

Upgrading

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.6.0; varyk-std gains Value. Nothing in 0.6.0 breaks an existing package: before 1.0, a new feature now bumps the minor version, as a breaking change does. After cargo install varyk, run varyk check in a package, and it says what to change: the varyk-std line in Cargo.toml, or cargo update -p varyk-std.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts.

What is next

First, varyk-sql 0.1.0, which ships with this release and has its own post: SQLite, Postgres, and MySQL on sqlx, with the query text a literal, so a query built from input is a compile error.

Then milestone 5b4, varyk-http and the golden path: an HTTP server with an explicit route table, an HTTP client, which brings the other half of the type parameter, for sending a Varyk value out, and the bar for all of milestone 5, a users API on a database that is varyk init, varyk add http sql, one file, and varyk run away. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Try writing a facade for a crate you use, and tell us where it hurts: the issues are the place.

Varyk 0.5.0: packages

2026-10-02T00:00:00+00:00

Varyk 0.5.0 is on crates.io. It is milestone 5b2 of the roadmap, the third part of the batteries for services. Milestones 5a and 5b1 gave Varyk, a language for backend services that compiles to Rust, the data a service works with and the way it waits: JSON, configuration, logging, tests, and tasks. Milestone 5b2 adds the way Varyk code is shared: a Varyk package uses another Varyk package by name, with no Rust file in between, and every package is built from the Varyk its author wrote. It comes before HTTP and the database because they will be packages too.

What is in it

A package is named by its key. Until now, Varyk code reached any other package, a Varyk library included, through a .rs file of its own, a facade. Now a Varyk package listed in [dependencies] is named in Varyk code like a module, by its key, with each - read as _. With units = { path = "../units" } in Cargo.toml:

use units::length::Meters;

fn total(a: Meters, b: Meters) -> Meters {
    units::length::add(a, b)
}

There is no new syntax. You choose the key, so sql = { package = "varyk-sql", version = "0.5" } would be sql:: in your code, and two packages cannot share a name. A local module of the same name wins over a package. A dependency is a Varyk package when its folder has src/lib.vr, whether it comes from a path, a registry, or git. A Rust crate is still never named from Varyk code: it is called from a .rs facade, as before, and naming one is V0110.

Packages that use packages. A package may use packages, to any depth: in the new examples, trip uses route, and route uses units. Each package sees only the packages its own Cargo.toml lists. If route gives you a Meters of units and your package lists route but not units, holding that value is V0115, and the help is the line to add. When cargo picks two versions of one package, they are two packages, and V0115 names both.

What a package gives you. Everything it marks pub that its users can reach: functions, structs with their pub fields, enums, methods, and the pub items of its .rs modules. They behave like your own: parameters borrow, mut parameters change the caller's value, an async function is awaited or started, and a match on its enum is checked for every case. A library cannot hand out a type its users could not name, so a pub function that returns a type of a private module is V0105 in the library itself. Two things stay inside a package: JSON and configuration conversions, so a json or env call on another package's type is V0210 (convert it in its own package), and its #[test] functions. And when any package in a build writes log lines, the program sets up logging, so they are not lost.

What runs when you build. Varyk is for services that face the network, so this release makes one promise about what runs on your machine. When varyk build, varyk run, or varyk test builds your program, the Rust of every Varyk package in it is exactly that package's own .rs files plus what your compiler generates from its .vr files. Nothing else in the package is compiled or run: not its build.rs, and not generated Rust its publisher shipped. varyk asks cargo which packages the build uses, checks every Varyk package from its .vr sources, and builds each as a crate of its own under target/varyk/packages/. What runs is what a reader can review. The package's own .rs files, the Rust crates it depends on, and their build scripts are Rust, visible as files and lines of Cargo.toml, and rustc's to judge, as for your own code.

The promise covers build, run, and test, and the reference names the one command it does not: varyk publish. cargo publish verifies a crate by building it as a plain cargo user would, so publishing compiles a Varyk dependency's shipped Rust, and any build.rs it was published with, on the publisher's machine. --no-verify after -- skips that.

What is refused. Cargo would build a Varyk package on its own, outside that promise, if it were reached any other way, so V0401 refuses a Varyk package under [dev-dependencies], one marked optional that a feature turns on, and one reached through a Rust crate, even when it is also used the supported way. It also refuses a Varyk package with the same name and version as another Varyk package of the build, or as a package that comes from a path. Naming a dependency marked optional in Varyk code is V0401 too, because cargo may leave it out of the build.

Varyk builds Varyk. A package's Cargo.toml now names its .vr root as cargo's target:

[[bin]]
name = "trip"
path = "src/main.vr"

or [lib] with path = "src/lib.vr" for a library. That is what lets cargo's own tools, such as cargo add, cargo update, and cargo tree, read the package. varyk init writes three files, Cargo.toml, .gitignore, and src/main.vr, and no build.rs and no stub, and varyk emit, which the build script ran, is gone. A source package is built with varyk build, not with plain cargo build, since its root is Varyk, not Rust. A Varyk crate published with varyk publish still carries its generated Rust, so a Rust project uses it with plain cargo, as any crate.

New diagnostic codes. V0115 is a value of a package your package does not list, or of another version of one it does. V0405 is cargo failing to work out which packages the build uses, for example a path dependency whose folder is missing, with cargo's own message in the note. V0406 is a Cargo.toml that does not name its .vr root, with the lines to add. The language reference has the new section, and the error codes the full table.

Two new example packages show it, and the examples page has them with their output: route, a library whose legs have a length in Meters of the package units, and trip, a program that uses both. This is trip's Cargo.toml:

[package]
name = "trip"
version = "0.1.0"
edition = "2024"

[[bin]]
name = "trip"
path = "src/main.vr"

[dependencies]
route = { path = "../route" }
units = { path = "../units" }
varyk-std = "0.5.0"

and its src/main.vr:

async fn main() {
    let legs = vec![
        route::leg("Home", "Mill", 800),
        route::leg("Mill", "Lake", 900),
    ];
    let sum = units::length::add(route::total(legs), units::length::Meters { value: 0 });
    println!("total {} meters", sum.value);
    let best = route::longest(legs);
    println!("longest {} to {}, {} meters", best.from, best.to, best.length.value);
    for text in vec!["{\"name\": \"Lake\", \"minutes\": 12}", "Lake at noon"] {
        match route::parse_stop(text) {
            Ok(stop) => println!("stop {}, {} minutes", stop.name, stop.minutes),
            Err(_) => println!("no stop"),
        }
    }
    let minutes = route::walking_minutes(sum.value).await;
    println!("about {} minutes on foot", minutes);
}

It prints:

total 1700 meters
longest Mill to Lake, 900 meters
stop Lake, 12 minutes
no stop
about 21 minutes on foot

route::longest gives back one of the legs it was given, not a copy, as a function of your own would, and route::walking_minutes is an async function awaited across the package line. trip writes no log line itself, but route warns on stderr when it cannot read a stop, so the program sets up logging for it.

The breaking changes

A package's Cargo.toml must name its .vr root, [[bin]] with path = "src/main.vr" or [lib] with path = "src/lib.vr"; without it, varyk check reports V0406, and its help gives the lines. varyk emit is removed. varyk init no longer writes build.rs or a stub, and a source package is built with varyk build, not plain cargo build. A build.rs or src/main.rs left by an earlier varyk init is never read, so you can delete them. build in [package] may only be left out or false.

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.5.0. After cargo install varyk, run varyk check in a package, and it says what to change.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts.

What is next

Milestone 5b2 also redraws the rest of milestone 5. varyk-std stays the small runtime every program has: Error, tasks, json, env, and log. Anything heavy, the HTTP server and client, SQL, MongoDB, Redis, is a package the writer adds, so a program that prints a line never compiles a web server or a database driver. Official packages are named varyk-*, such as varyk-sql and varyk-http, and packages from the community *-varyk. With packages in place, a battery is written once as a package, by this project or by anyone, and needs no work in the compiler.

Milestone 5b3 is facades and varyk-sql: what a .rs facade can say, such as a function that takes or returns any Varyk data type, pub use, and varyk add shorthands for official packages; then varyk-sql on sqlx, for SQLite, Postgres, and MySQL, where the query text is written in the program, so a query built from input is a compile error. Milestone 5b4 is varyk-http and the golden path: an HTTP server with an explicit route table, an HTTP client, and the bar for all of milestone 5, a users API on a database that is varyk init, varyk add http sql, one file, and varyk run away. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Try splitting a small service into packages and tell us where it hurts: the issues are the place.

Varyk 0.4.0: async functions and tasks

2026-10-01T19:00:00+02:00

Varyk 0.4.0 is on crates.io. It is milestone 5b1 of the roadmap, the second part of the batteries for services. Milestone 5a gave Varyk, a language for backend services that compiles to Rust, the data a service works with: JSON, configuration, logging, and tests. Milestone 5b1 adds the way a service waits: async and .await on a built-in runtime, and tasks that run alongside each other, so that a handler can fetch three things at once instead of one after another.

What is in it

async fn and .await. async before fn, on a top-level function or a method, makes a function that can wait, and .await after a call runs it and gives its result. Parameters still borrow by default, exactly as in any other function. async fn main() runs on a built-in runtime, multi-threaded with one worker per core, and #[test] async fn is a test that runs on a runtime of its own. Calling an async function from an ordinary one is an error, with a fix-it that adds async.

Calls that start tasks. There is no spawn. A call to an async function followed by .await runs in place; the same call without .await starts the function at once and gives a task, a Task<T> whose type is worked out from the call and never written, as calling an async function does in JavaScript. Two calls started one after the other really do overlap, and each is waited on later with .await:

let late = slow(2);
let early = Counter { step: 1 }.next(6);
println!("fast then slow: {} and {}", early.await, late.await);

It prints fast then slow: 7 and 2: the call started second finishes first.

A task that is dropped is cancelled, so no work outlives the code that started it unless you ask: a ? that returns early stops the tasks the function had started. .detach() lets a task run on with nobody waiting for it. A started call whose task is thrown away, such as a bare fetch_user(7);, is an error, so a forgotten .await is caught by the compiler instead of turning into background work.

Waiting on many. Task::all waits for a list of tasks and gives their results in order. When the tasks can fail, it gives the first error to arrive, as JavaScript's Promise.all does, and, unlike it, cancels the tasks still running; Task::all_settled waits for every task and keeps each outcome, as Promise.allSettled does. A list of tasks comes from vec! or from a chain: ids.iter().map(|id| fetch(id)).collect() starts one task per id.

Ownership without new syntax. A started call may outlive the function that made it, so its arguments are given to the task: a number is copied, a value the function owns moves in, and a parameter, which belongs to the caller, needs .clone(). That is the one place a value is handed over, so Varyk still has no ownership-transfer syntax, and the function itself still borrows.

Shared. Shared::new(config) puts one struct where many tasks can read it, and s.clone() gives each task a handle, not a copy. Fields and methods are reached straight through it, and nothing reached through it can be changed. Underneath it is Rust's Arc; ten thousand tasks reading one configuration take ten thousand handles and one value.

time::sleep and async Rust. time::sleep(ms) waits without holding up other tasks. pub async fn and async methods in .rs modules are imported like any other, and are awaited or started the same way.

No Send or Pin to write. Every type Varyk declares can move between threads, so the bounds Rust needs for a multi-threaded runtime never appear in Varyk code. A value from a .rs module that cannot move to or be shared with another thread, such as one holding an Rc or a RefCell, is reported at the Varyk line that starts the task, as V0901, naming the Rust type.

New diagnostic codes. V0211 is .await or an async call outside an async fn, V0212 an .await on something that cannot wait, V0213 a task that would be thrown away, V0214 async functions that call each other in a cycle, V0215 a task used anywhere but where it is made, and V0216 a Shared that is not a struct or is written where it cannot go. V0309 is a started call that would change a value the caller can never see, V0310 a change through a Shared, V0311 an async function that returns part of a parameter, and V0901 the thread rule above. The language reference has the section, and the error codes the full table.

Three new example programs show it in use, and the examples page has them with their output: tasks, with calls that overlap, an async method, a detached task, and async tests; fanout, which waits on calls that can fail with Task::all and Task::all_settled; and shared, which gives one Shared value to ten thousand tasks. This is fanout.vr:

async fn price(item: i64) -> Result<i64, Error> {
    time::sleep(10 * item as u64).await;
    if item == 3 {
        return Err(Error::new(format!("no price for item {}", item)));
    }
    Ok(item * 12)
}

async fn prices(items: Vec<i64>) -> Result<Vec<i64>, Error> {
    let found = Task::all(items.iter().map(|item| price(item)).collect()).await?;
    Ok(found)
}

async fn main() {
    let good: Vec<i64> = vec![1, 2, 4];
    let bad: Vec<i64> = vec![1, 2, 3];
    match prices(good).await {
        Ok(found) => println!("prices: {} + {} + {}", found[0], found[1], found[2]),
        Err(e) => println!("failed: {}", e.message()),
    }
    match prices(bad).await {
        Ok(found) => println!("prices: {}", found.len()),
        Err(e) => println!("failed: {}", e.message()),
    }

    let items: Vec<i64> = vec![1, 2, 3, 4];
    let outcomes = Task::all_settled(items.iter().map(|item| price(item)).collect()).await;
    let mut n: i64 = 1;
    for outcome in outcomes.iter() {
        match outcome {
            Ok(value) => println!("item {}: {}", n, value),
            Err(e) => println!("item {} failed: {}", n, e.message()),
        }
        n = n + 1;
    }
}

It prints:

prices: 12 + 24 + 48
failed: no price for item 3
item 1: 12
item 2: 24
item 3 failed: no price for item 3
item 4: 48

The breaking changes

async and await were already reserved words, and now they are keywords. Task and Shared are reserved as Error is: they cannot name a struct, an enum, a module, or a use, nor a pub struct or enum of a .rs module. time is reserved as json, env, and log are: it cannot name a module, a struct, or an enum, or be brought in with use. A program with its own struct named Task renames it; the compiler's own todo example now calls its struct Item.

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.4.0. varyk-std now holds the runtime too, so a program with an async main needs it at the compiler's version: after cargo install varyk, run varyk check, and it says what to change.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts.

What is next

Milestone 5b2 is HTTP and the database: an HTTP server on a proven Rust crate, with the application state every handler shares held in a Shared, an HTTP client on the same stack, and databases through one API. It meets the bar for all of milestone 5: a users API on a database is varyk init, one file, and varyk run away, within fifteen minutes of cargo install varyk. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Try starting a few tasks in a small service and tell us where it hurts: the issues are the place.

Varyk 0.3.0: data, config, logging, and tests

2026-10-01T10:00:00+02:00

Varyk 0.3.0 is on crates.io. It is milestone 5a of the roadmap, the first part of the batteries for services. Milestone 4 made the everyday code of a service easy to write in Varyk, a language for backend services that compiles to Rust. Milestone 5a adds what a service does with data before it talks to the network: read and write JSON, take its settings from the environment, write logs, and test itself.

What is in it

varyk-std and Error. A new crate, varyk-std, is the one crate Varyk code reaches without a facade; every other crate is still reached through a .rs file. It is behind Error, a built-in error type with a message: Error::new("...") makes one, e.message() reads it, and it prints with {}. Every standard call that can fail returns Result<T, Error>, so ? works across all of them with no conversions.

JSON, with attributes. json::parse reads a struct from JSON text and json::stringify writes one. Structs, Option, Vec, HashMap with string keys, and enums whose variants carry no data all go through. Three attributes adjust the keys: #[rename("userName")] on a field or a variant, #[default(18)] for a field the text leaves out, and #[skip] for a field that is neither read nor written, such as a password hash. Varyk derives serde's traits only for the types a json or env call reaches, so a program that never calls json or env has no serde in it, and a type that cannot go through JSON is an error at the call.

Configuration from the environment. let c: Config = env::parse()?; fills a struct from environment variables, then from a .env file in the current directory, then from #[default]. A field database_url is read from DATABASE_URL, and #[rename] changes that. A variable that is not set, or does not read as its type, is an Error that names it.

Logging. log::debug, log::info, log::warn, and log::error take a format string and arguments exactly as println! does, and write a line to stderr. LOG sets the level, info when unset, and LOG_FORMAT=json writes one JSON object per line instead of text, with no change to the code.

Tests. A function marked #[test] is a test, in any module, and assert and assert_eq check results inside one. varyk test builds the program with its tests and runs them; varyk build and varyk run leave them out. A failing check names the Varyk file and line.

varyk init, varyk add, and the version check. varyk init now writes varyk-std into Cargo.toml at the compiler's own version, and .env into .gitignore, so a local secrets file is never committed. varyk add runs cargo add in the package with the arguments you give. varyk check reads the varyk-std line and Cargo.lock, and when they do not match the compiler it says so as V0404, with the line to write or cargo update -p varyk-std to run.

New diagnostic codes. V0112 is an attribute Varyk does not have, or one in a place it cannot go. V0113 is a reserved name. V0114 is a test with parameters or a return type, a call to a test, or assert outside a test. V0209 is an attribute value that does not fit, and V0210 a type that cannot go through JSON or the environment. V0404 is the varyk-std version check. The language reference has the full table.

Three new example programs and a new package show it in use, and the examples page has them with their output. The users package puts them together: a store of users read from JSON, configuration from a .env file, logging, and three tests. This is json.vr:

enum Role {
    Admin,
    #[rename("member")]
    Member,
}

struct User {
    id: u32,
    #[rename("userName")]
    user_name: string,
    role: Role,
    nickname: Option<string>,
    tags: Vec<string>,
    #[default(18)]
    age: u8,
    #[skip]
    password_hash: Option<string>,
}

fn role_name(role: Role) -> string {
    match role {
        Role::Admin => "admin",
        Role::Member => "member",
    }
}

fn load(body: string) -> Result<User, Error> {
    let u: User = json::parse(body)?;
    Ok(u)
}

fn main() {
    let text = "{\"id\": 7, \"userName\": \"ann\", \"role\": \"member\", \"tags\": [\"a\", \"b\"], \"password_hash\": \"x\"}";
    match load(text) {
        Ok(u) => {
            println!("{} {} {}", u.id, u.user_name, role_name(u.role));
            println!("{} tags, age {}, nickname: {}", u.tags.len(), u.age, u.nickname.is_some());
            println!("{}", json::stringify(u));
        }
        Err(e) => println!("error: {}", e),
    }
    let bad = "{\"id\": 1, \"userName\": \"bo\", \"role\": \"Admin\", \"tags\": [], \"age\": 300}";
    match load(bad) {
        Ok(u) => println!("{}", u.id),
        Err(e) => println!("error: {}", e),
    }
}

It prints:

7 ann member
2 tags, age 18, nickname: false
{"id":7,"userName":"ann","role":"member","nickname":null,"tags":["a","b"],"age":18}
error: invalid value: integer `300`, expected u8 at line 1 column 67

The breaking changes

s.parse() returns Result<T, Error> instead of Option<T>, so ? works on it in a function that returns Result<_, Error>, and the error names the text. Code that wanted the old Option writes two statements, since the expected type does not reach a method's receiver:

let r: Result<i32, Error> = text.parse();
let n = r.ok();

The new names are reserved: json, env, and log cannot name a module, a struct, an enum, or a use; Error cannot name a struct, an enum, a module, or a use; assert and assert_eq cannot name a function; and no function, method, struct, enum, module, or use name may start with varyk_, which is kept for what the compiler adds to the Rust it writes. Local variables and fields may still use any of these names.

The three crates, varyk, varyk-syntax, and varyk-std, are released together as 0.3.0. A package that uses varyk-std needs it in [dependencies] at the compiler's version: after cargo install varyk, run varyk check, and it says what to change.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts.

What is next

Milestone 5 is now three milestones. Milestone 5b1 is async/await on a built-in runtime and spawn, gated on two open questions, the runtime shape and ownership-transfer syntax. Milestone 5b2 is HTTP and the database: an HTTP server and client on one stack, and databases through one API. The bar for all three is one golden path: a users API on a database is varyk init, one file, and varyk run away, within fifteen minutes of cargo install varyk. It is met at the end of 5b2. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Try writing one small service and tell us where it hurts: the issues are the place.

Varyk 0.2.0: closures, iterators, and patterns

2026-09-29T00:00:00+00:00

Varyk 0.2.0 is on crates.io. It is milestone 4 of the roadmap, and it is about the language: the everyday code of a service that milestone 3 made awkward. Milestone 3 connected Varyk, a language for backend services that compiles to Rust, to Cargo and the Rust ecosystem. Milestone 4 adds closures, chains over collections, richer patterns, HashMap, and functions that return part of what they are given without a copy.

What is in it

Closures, as the argument of a call. |n| n * 2 works as the argument of map, map_err, filter, any, all, and find. A closure has one parameter with no type written, reads the names around it, and never changes them. It is never a value of its own: a closure in a let, passed to a Varyk function, or returned is an error.

Chains. A chain starts at v.iter(), s.split(sep), m.keys(), or m.values(), passes through any number of maps and filters, and ends at collect, count, sum, any, all, or find, or as the head of a for. In the generated Rust it is written as it is.

let evens = numbers.iter().filter(|n| n % 2 == 0).count();
let names: Vec<string> = users.iter().map(|u| u.name.clone()).collect();

Patterns. if let and while let; variants with named fields, Event::Click { x: 0, y }; nested patterns, Some(Shape::Circle(r)); literals and ..= ranges, 90..=100; and match on numbers, bool, and strings. Varyk checks that every value fits an arm (V0204) and that every arm can run (V0205), and the error names a value no arm fits.

HashMap, ? on Option, as, and parse. HashMap has insert, get, contains_key, len, keys, and values. ? now works on an Option in a function returning one. as converts between number types with Rust's rules, s.parse() gives an Option, and Option and Result get their first methods: is_some, is_ok, is_err, unwrap_or, map, ok_or, ok, and map_err. There is still no unwrap or expect: a value that is absent is something to handle, not a reason to stop the program.

.clone() and == on your own types. A struct or enum whose fields allow it gets Clone and PartialEq derived, so .clone() and == work on it, and derives read from an imported Rust type count too.

Getters without copies. A function may return part of one of its parameters, and nothing is written for it: Varyk sees from the body that every return is part of the same parameter. display_name needed a .clone() in milestone 3; now the generated Rust returns a reference into self:

fn display_name(self) -> string {
    if self.nickname.is_empty() { self.name } else { self.nickname }
}

fn display_name(&self) -> &str {
    if self.nickname.is_empty() {
        &self.name
    } else {
        &self.nickname
    }
}

The result is another name for part of the value passed in, like a field, so that value cannot change while the result is used. A Rust function in a .rs file whose elided lifetime ties its result to one parameter, such as fn first_word(s: &str) -> &str, imports the same way.

New diagnostic codes. V0208 is a value that must be used where it is made: the Option of get on a stored value, which is looked into right there with match or if let, or a chain left unfinished. V0308 is a function returning part of one parameter in one place and part of another in another. The language reference has the full table.

Six new example programs show it in use, and the examples page has them with their output. This is words.vr:

fn main() {
    let text = "the cat saw the dog and the cat ran";
    let mut counts: HashMap<string, i32> = HashMap::new();
    for word in text.split(" ") {
        let n = counts.get(word).unwrap_or(0) + 1;
        counts.insert(word.clone(), n);
    }
    let mut words: Vec<string> = counts.keys().map(|w| w.clone()).collect();
    words.sort();
    for word in words {
        if let Some(n) = counts.get(word) {
            println!("{} {}", word, n);
        }
    }
    println!("{} distinct words", counts.len());
}

The breaking change

The breaking change is in the varyk-syntax crate, not in Varyk: its syntax tree gained new expressions, statements, and patterns, and Rust code that matches on that tree must handle them. Every program in the compiler's examples and tests that 0.1.0 accepted is still accepted.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts.

What is next

Milestone 5 is the batteries for services: HTTP, JSON, databases, configuration, logging, varyk test, and async/await on a built-in runtime, with one golden path as the bar, a users API on a database that is varyk init, one file, and varyk run away. varyk fmt and the interop items once planned for milestone 4 moved to milestones 5 and 6. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Try writing one small service and tell us where it hurts: the issues are the place.

Varyk 0.1.0: packages and interop

2026-09-27T14:00:00+02:00

Varyk 0.1.0 is on crates.io. It is milestone 3 of the roadmap, and it connects Varyk, a language for backend services that compiles to Rust, to the Rust ecosystem. Milestones 1 and 2 made a single .vr file, with the modules it declares, into a running program. Milestone 3 makes Varyk code a Cargo package, with a Cargo.toml, crates from crates.io called through a .rs facade, modules at any depth, use, private fields, Rust structs and enums imported from .rs modules, plain cargo build through a build.rs, and publishing to crates.io as a crate whose consumers need only cargo.

The minor version moved because one rule changed. Until 1.0, a breaking change bumps the minor version, and this release has one, described below.

What is in it

A Varyk package is a Cargo package. Its crate root is src/main.vr for a binary or src/lib.vr for a library, Cargo.toml is the only manifest, and it must say edition = "2024" (V0400 otherwise). varyk check, build, and run with no file argument find the package from the current directory. varyk init writes the package and a build.rs, so plain cargo build and cargo run work too, with varyk on the PATH (or $VARYK naming it), and CI for the compiler asserts that both give the same output. build.rs calls the new varyk emit, which writes the generated Rust tree to a directory without running cargo. Single-file mode, varyk run hello.vr, is unchanged.

Modules at any depth. A module may declare modules; children live in a directory named after their parent, as shop.vr and shop/mod.vr alike, and paths with crate::, self::, or super:: resolve everywhere a path can appear. Visibility is Rust's: a module or item without pub is visible in its declaring module and that module's descendants, and a pub item may not name a type its users cannot see.

use. use crate::shop::cart::Cart; and use shop::cart as c; alias modules, structs, enums, and functions inside the package. A use cannot start with the name of a crate, std included, which brings us to dependencies.

Cargo dependencies. cargo add works unchanged. A crate is called from a Rust file in the same package, which exposes the plain functions and types your Varyk uses, imported the way Rust functions have been since milestone 1. The docs call that file a facade. Most crate APIs are generic, and Varyk has no generics in its surface, so the facade is where the concrete API gets written, and a package with its facade publishes as a plain crate. Whether Varyk code should ever use a crate directly, with no facade, is an experiment for after traits exist; it is recorded as an open question in the specification and as unscheduled on the roadmap.

Rust structs, methods, and enums import. A non-generic pub struct with named fields in a .rs module becomes a Varyk struct, its inherent pub fns become methods, and &self and &mut self map to self and mut self. A field whose Rust type Varyk cannot map is present but unusable, with an error that names the type. Enums with unit and tuple variants import too (their methods not yet), and Varyk checks that a match on one covers every variant.

Errors from rustc point at the right file. An error or warning rustc reports in one of your own .rs files is shown at your file and line, unchanged, as rustc worded it. The Rust Varyk generates should never be rejected; if it is, the backend's line-level source map reports it as V0900 at the Varyk line that produced it, carrying rustc's message and asking you to report it as a bug. Warnings are allowed per generated item, so your own .rs files warn normally, and --message-format=json carries those warnings too; under varyk run, whose standard output is the program's own, the JSON goes to standard error.

Publishing. varyk publish runs the full check, assembles a plain Rust crate with the generated .rs files, the .vr sources beside them, and no build.rs, and runs cargo publish there, passing on anything after --. Binaries and libraries both publish. A consumer that only has cargo adds a published Varyk library like any crate, and cargo install of a published Varyk binary works like any other. varyk publish --assemble-only stops after the assembly and publishes nothing.

New diagnostic codes. V0110 is a use naming a crate; call it from a .rs module instead. V0111 is a path Varyk cannot follow, such as super in the entry file or a use ending at an enum variant. V0400 to V0403 are about Cargo.toml: an edition other than 2024, a workspace setting or platform-only dependencies, a path in a target table, and a manifest that cannot be used. V0900 is the generated-Rust error above. The language reference has the full table.

The three milestone-3 example packages are in the compiler's examples: greeting, a binary built by varyk run and by cargo run; matcher, a facade over a registry crate with a struct, methods, and an enum imported into Varyk; and units, a library assembled by varyk publish --assemble-only and used by a cargo-only consumer.

This is matcher. Cargo.toml names the crate:

[package]
name = "matcher"
version = "0.1.0"
edition = "2024"

[dependencies]
regex-lite = "0.1"

src/text.rs is the facade:

// A facade: Varyk code never names a crate, so this file wraps
// `regex_lite` in a struct, methods, and an enum Varyk can import.

pub struct Matcher {
    re: regex_lite::Regex,
}

impl Matcher {
    pub fn new(pattern: &str) -> Matcher {
        let re = regex_lite::Regex::new(pattern).expect("the pattern should be a valid regex");
        Matcher { re }
    }

    pub fn is_match(&self, s: &str) -> bool {
        self.re.is_match(s)
    }

    pub fn count(&self, s: &str) -> usize {
        self.re.find_iter(s).count()
    }
}

pub enum Kind {
    Word,
    Number(i32),
}

pub fn classify(s: &str) -> Kind {
    // Deliberately unused: rustc's warning about it shows through
    // `varyk build` at this file and line, as Rust warnings do.
    let trimmed = s.trim();
    match s.parse::<i32>() {
        Ok(n) => Kind::Number(n),
        Err(_) => Kind::Word,
    }
}

And src/main.vr uses it like any Varyk module:

// expected output:
// apple: word, 0 digit runs
// 42: the number 42, 1 digit runs
// route 66 or 101: word, 2 digit runs
// 2 of 3 contain digits

mod text;

fn describe(kind: text::Kind) -> string {
    match kind {
        text::Kind::Word => "word",
        text::Kind::Number(n) => format!("the number {}", n),
    }
}

fn main() {
    let digits = text::Matcher::new("[0-9]+");
    let mut inputs: Vec<string> = Vec::new();
    inputs.push("apple");
    inputs.push("42");
    inputs.push("route 66 or 101");

    let mut with_digits: usize = 0;
    for s in inputs {
        if digits.is_match(s) {
            with_digits = with_digits + 1;
        }
        println!("{}: {}, {} digit runs", s, describe(text::classify(s)), digits.count(s));
    }
    println!("{} of {} contain digits", with_digits, inputs.len());
}

varyk run in the package prints rustc's warning that trimmed is unused, at src/text.rs line 31, which the example keeps on purpose to show a warning in your own Rust, and then the four lines of output.

The breaking change: fields are private unless `pub`

In milestone 2 every field of a pub struct was public. From 0.1.0 a field follows the same rule as everything else: private unless pub, visible in the struct's own module and its descendants, which includes the struct's own methods.

pub struct User {
    pub name: string,
    age: i32,
}

Reading, assigning, or naming a private field from another module is an error with a note offering both ways out, pub on the field or a pub fn, because making every field public is often the wrong fix. The milestone-2 examples needed no source changes when the rule landed, because none of their fields crossed a module boundary; if yours do, add pub to the fields other modules read.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk init hello
cd hello
varyk run

The getting started page goes from there, and the language reference describes everything the compiler accepts.

What is next

Milestone 4 is closures, iterators, if let, HashMap, borrowed return values, and varyk fmt, and more interop: nested modules in .rs files, Rust tuple and unit structs, derives on imported Rust structs usable from Varyk, .rs signatures naming Varyk types, and importing a published Varyk library straight into Varyk code. Milestone 5 is the batteries for services: HTTP, JSON, databases, configuration, logging, tests, and async/await on a built-in runtime. The roadmap has every item, and nothing there is a date.

Varyk is experimental and pre-1.0. Try building one small package and tell us where it hurts: the issues are the place.

Varyk 0.0.2: enums, matching, methods, and collections

2026-09-26T00:00:00+00:00

Varyk 0.0.2 is on crates.io. Varyk is a language for backend services that compiles to Rust, and this release, milestone 2 of the roadmap, brings the language core a small program needs. Milestone 1 proved borrow-by-default on six programs; this release adds enums and match, for, methods, Option, Result, Vec, ?, format!, and a deliberate string copy, and it keeps every milestone-1 rule. Calls never write &, mutation is declared with mut, and the compiler adds no allocation except a string literal stored into a value you own and the copy you ask for with .clone().

What is in it

enum Shape {
    Circle(f64),
    Rect(f64, f64),
    Point,
}

fn area(shape: Shape) -> f64 {
    match shape {
        Shape::Circle(radius) => 3.14 * radius * radius,
        Shape::Rect(w, h) => w * h,
        Shape::Point => 0.0,
    }
}

fn main() {
    let shapes = vec![Shape::Circle(1.0), Shape::Rect(2.0, 3.0), Shape::Point];
    for shape in shapes {
        println!("{}", area(shape));
    }
}

It prints 3.14, 6, and 0. Every new construct follows the same idea as the old ones: you write what the program does, and the compiler decides how the value is passed.

Enums with unit and tuple variants, and match on enums, Option, and Result with one-level patterns. Varyk checks the arms itself, so a match that forgets a variant is a plain-word error before cargo runs.
for over integer ranges and over a Vec.
impl blocks with self and mut self methods and associated functions. A method that reads self borrows it; one that writes mut self borrows it mutably, and the caller sees the change.
Option, Result, and Vec in types, written as in Rust, with Some, None, Ok, Err, Vec::new(), vec!, push, pop, len, and indexing. None, Vec::new(), Ok, and Err take their type from where they go, the way an integer literal does.
? on a Result whose error type is the function's own.
format! for building strings. + on strings is rejected with a fix-it that says to use it, so every allocation is visible at the call.
usize for lengths and indexes, matching rustc's types.
s.clone() on a string: the one explicit copy, Rust's own spelling, with the cost visible where it happens. It answers an open question from milestone 1.

Matching and iterating borrow, like everything else. A match on a place never moves it; a name bound by a pattern, or the loop variable of a for over a Vec, is an alias of part of the value, and changing or giving away the whole while an alias is still in use is an error. Milestone 1 had this rule implicitly and one bug around it; milestone 2 states it and applies it everywhere.

The six milestone-2 programs are in the compiler's examples, including a small todo program with a Task struct, a Status enum, methods, and format!, spread over two files. The language reference describes everything the compiler accepts today; the reference as it stood at this release, docs/language.md at the varyk-v0.0.2 tag, has a section "Not in milestone 2" that lists what 0.0.2 rejects and why: enum variants with named fields, nested and literal patterns, methods on Option and Result, closures, iterators, if let, HashMap, and returning part of a borrowed value, which stays a .clone() until milestone 4.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk run enums.vr

The getting started page goes from there.

The roadmap, renumbered

The old milestone 2 covered four independent areas. This release takes the language core only, and the rest moved down the list: packages, Cargo dependencies, use, nested modules, field-level pub, Rust struct import, and publishing are now milestone 3; closures, iterators, if let, HashMap, and varyk fmt are milestone 4; the batteries for services, HTTP, JSON, logging, and async, are milestone 5. Nothing there is a date.

Varyk is experimental and pre-1.0: until 1.0, a breaking change bumps the minor version. Milestone 3 has one, private struct fields, so the release after it is 0.1.0.

If you think the bet is wrong, or right, the issues are the place to say so.

Announcing Varyk 0.0.1

2026-09-25T00:00:00+00:00

Varyk is an experimental language for APIs, workers, and microservices that compiles to Rust. Rust is what a service should run on: memory safety without a garbage collector, native speed, and an ecosystem that already has everything a service needs. It is also a lot to hold in your head when all you want is to handle a request. Varyk keeps what makes Rust strong and removes the ceremony from application code, and the Rust compiler checks everything it generates. Today the first release, 0.0.1, is on crates.io, and the compiler repository is public.

The story of how I got here, through JavaScript, Python, TypeScript, Go, and Swift, is in Why I built Varyk.

What is in it

This release is milestone 1: a small compiler that proves the approach. You write simple Varyk, and it becomes readable Rust that rustc checks like any other Rust code.

struct User {
    name: string,
}

fn rename(mut user: User) {
    user.name = "Bob";
}

fn print_user(user: User) {
    println!("{}", user.name);
}

fn main() {
    let mut user = User {
        name: "Alice",
    };

    print_user(user);
    rename(user);
    print_user(user);
}

It prints Alice, then Bob. varyk build --emit-rust shows the generated Rust.

The milestone-1 surface is deliberately small: functions, structs, if/else, while, one string type, println!, modules that resolve to .vr or .rs files, and calls into plain Rust functions. The language reference describes everything the compiler accepts, and the examples are the six programs it must build and run. Every error has a code, a plain-word message, and, where it can, a fix-it; --message-format=json prints them as JSON for tools and agents.

Try it

You need a stable Rust toolchain installed through rustup.

cargo install varyk
varyk run hello.vr

The getting started page goes from there.

What is next

Varyk is experimental and pre-1.0: syntax, diagnostic codes, and command-line flags may change, and a breaking change bumps the minor version. The next milestones add enums, match, for, methods, Option, Result, and ?, and then packages with Cargo.toml and Cargo dependencies. The batteries a service needs, HTTP, JSON, databases, and async, come in milestone 5. The roadmap has the full list, and the design page explains why the language is shaped this way.

If you think the bet is wrong, or right, the issues are the place to say so.

Why I built Varyk

2026-09-24T14:31:00+02:00

Varyk is an experimental language for backend services: you write simple, Go-like application code, and you ship a native Rust binary. This post is the story of why I started building it.

I came to Varyk through the languages I built services in before it. JavaScript, then Python, then TypeScript: productive languages, but working with data without real types was harder than it needed to be, and TypeScript's types are only as strong as the JavaScript underneath them. I also needed performance those languages could not give me. So I went looking for a language that was fast and had a type system I could lean on.

Go is simple, and I like that. But it has a garbage collector, with the runtime and memory overhead that come with it, and a syntax I never took to. Swift is a good language whose server ecosystem is too small for the microservices I build. Rust has the ideology I believe in: ownership instead of a garbage collector, safety enforced by the compiler, native performance, and an ecosystem that already has everything a service needs. I love it. Day to day, though, it is difficult to work with, and much of the difficulty comes from quirks that have nothing to do with the service being written.

What I wanted did not exist: Rust's ecosystem, guarantees, and performance, with application code as simple as Go. Varyk is that language. It is for the application: kernels, database engines, and borrow-heavy libraries stay in Rust, in a .rs file beside your Varyk, in the same build.

What that means in practice

Varyk compiles to Rust. Every program becomes ordinary Rust that the Rust compiler checks, so the safety and the speed are Rust's own, and what you deploy is one native binary with no garbage collector. A Varyk package is a Cargo package: any crate on crates.io is available through a small .rs file in the package, a facade, with no bindings to generate. What Varyk removes is the part of Rust you have to hold in your head. The Why page lays out what that costs in Rust and how Varyk takes it out; the examples show what the code looks like.

Varyk is experimental and pre-1.0, and the batteries a service needs, HTTP, JSON, databases, and async, are milestone 5. If the bet sounds wrong to you, I would like to hear why: hello@varyk.com.