Wax FAQ

Wax is a programming language for parts of an application whose history matters. A Wax program can produce a recording of what happened while it ran. You can open that recording later and inspect any recorded moment.

Wax is designed to live inside an existing application. The rest of the application stays in its current language and remains in charge.

No. Wax is designed for progressive adoption. You can start with a small piece of an application to test it today. If it proves useful, the Wax boundary can grow with the project. Typed bindings keep that boundary explicit as it grows.

Wax was never meant to replace Rust, C++, C#, or the rest of your stack. Those languages are excellent and have mature ecosystems. Keep using your daily driver for its primary role. Let Wax handle the parts that benefit from a durable execution history.

Not as a dependency you can adopt and forget about. Production use during the preview means accepting possible breaking changes and validating updates against your workload. Direct support is strongly recommended before relying on Wax in production. An initial fit check does not require a paid commitment. Closing gaps for your use case and providing ongoing support would be paid work.

Logs and traces preserve the facts about your program that you thought were important at the time you wrote it. A core dump preserves one moment. These are useful, but they cannot answer a question that required history nobody chose to save.

Wax records enough of the program to reconstruct earlier state after the run has finished. The recording is a portable artifact that can be inspected and queried without keeping the original process alive.

Tools such as rr and WinDbg Time Travel Debugging let a debugger move through a recorded process. Wax takes the idea further by treating a recording as a typed API to the program’s past.

A recording is meant to stay useful after the original run. It is a file you can move to another machine or share with someone who is allowed to see its contents. Recordings can also be collected over time as a historical record of past runs. You can write new Wax code against any recorded moment while the original history remains unchanged.

A recording contains saved Wax state and the outside values that entered through declared host calls. It also carries the source and program metadata needed to understand that state.

Resources owned by the host stay outside the recording. Wax does not try to serialize a database connection or a file handle. It records the values the Wax program received from the host.

Wax does not strictly have to be its own language. Prototype front ends for subsets of MSIL and JVM programs exist internally and compile through Wax instead of running on the CLR or JVM. They may become supported in the future, but they would not be the primary surface for Wax.

For Wax, the reasons to make a new language outweigh the reasons to adapt an existing one. A subset is difficult to explain, and exact parity is hard when code does not run on its original runtime. Control from syntax through LSP behavior makes it possible to design the user experience as one system instead of chasing another language’s semantics and tooling.

Recording is not free. Storage cost depends on how much retained state changes and how often snapshots are kept, which you can tune. Host inputs and the amount of retained history matter too. More data costs more to store. Wax goes to heroic lengths to keep snapshots as small as possible.

Wax organizes recorded work into frames chosen by the host, such as an application update or tick. Per frame overhead is usually very low. Most frames only append the values received from the host, which are normally tiny. You only pay the cost of capturing a snapshot on a frame where one is actually taken.

Capturing a snapshot typically takes a few milliseconds and can happen asynchronously. It normally does not cause a visible hitch. Capture time grows mostly linearly with the amount of live Wax state. A serious evaluation should still measure the real workload. Recording and replay explains the main costs.

Wax keeps a rolling window rather than retaining an entire process forever. The limits are configured in frames and bytes. How much wall clock time that covers depends on the application.

A saved recording contains the history that remained in the window when it was written. Applications with more memory available can keep a larger window.

Treat a recording as sensitive application data. It contains source code and ordinary program state. User data and values returned by the host can be present too.

Recordings are not encrypted today. Wax may add an encryption layer in the future, but it currently makes no security promises about the file. If your application handles sensitive data, protect its recordings accordingly.

secret is an escape hatch for text that must not be remembered in plain text. Wax replaces that content with zeros before it enters the committed recording, so replay sees zeros instead of the original text. It is not a security layer. Other application state can still contain sensitive data, including anything the program derived from the secret. Do not share a recording unless the recipient is allowed to see what it contains.

On supported little endian machines, Wax promises byte for byte parity for the application state it captures. Changing the CPU architecture or operating system must not change that state.

The guarantee applies to the user’s Wax code and data. It does not cover the host process or require the generated Wax binary to be identical. A .wxs recording can be copied to another supported machine without conversion. The file contents remain identical, and replay must reconstruct the same Wax state.

Any deviation in Wax state is a serious correctness bug. It is not an accepted platform difference and is strictly against the determinism guarantee.

On its own, embedded Wax code has no way to talk to the outside world. It can only call the host APIs that the application declares for it. The host can choose to expose files, network services, or other resources through those APIs.

Wax is designed to sit inside another application, and the host keeps ownership of its resources. Values returned by host calls are typed and recorded so replay does not need to make those calls again.

The --standalone build mode synthesizes the small host needed to run a Wax app directly. It is useful for examples, command-line programs, and learning the language; embedding Wax behind an explicitly declared host API remains the primary production model.

Wax is memory safe by design. Wax code operates inside its own managed memory and cannot directly read or write host memory. Everything that enters or leaves Wax is marshalled through a declared host API.

null exists only in values declared as nullable. It cannot be observed through a nonnullable reference or dereferenced. Wax code must check or unwrap a nullable value before using it. Forcing a null value to unwrap causes a defined panic. Invalid operations such as an out of bounds array access also panic instead of becoming unsafe memory access.

A panic terminates that Wax app immediately. It cannot be caught inside Wax, and the app cannot resume afterward. At a declared host boundary, the runtime contains the panic and reports it to the host. The host process stays alive and can discard or restart the Wax app.

The promise is similar to WebAssembly. Code inside Wax has no ambient access to the rest of the system and can only use capabilities the host explicitly gives it. A serious bug in the Wax compiler or runtime could violate that promise, just as an implementation bug could violate WebAssembly’s sandbox, but that would be a Wax defect rather than accepted behavior.

Wax is free during the developer preview. The long term plan is for Wax to become a paid product, with a free tier for small independent creators and personal projects.

Pricing and transition terms have not been decided yet. Both will be announced before the preview ends. The preview page is the current source for these terms.

Yes. Commercial use is allowed at no charge during the preview. Anything you ship with a preview version of Wax will remain free to use with that version. You would only pay if you choose to upgrade to a version released after the preview.

You do not need separate permission or paid support to ship it. If you intend to rely on Wax in production during the preview, please get in touch. Free use does not include a support contract. Help on Discord is informal and offered on a best effort basis.

Wax is not open source today. It has been built independently over the last three years, and the focus now is finding a sustainable business model that can support its continued development.

The source model may change in the future, but there is no commitment to that today.

The long term goal is to build a company around Wax or some of the use cases it makes possible. Getting there means proving it in more projects and turning the current preview into a dependable product.

Conversations with potential partners and investors who want to help bring it there are welcome.

I use AI as a development tool. The ideas, prose, technical designs, specification, and planning behind Wax are my own.

I wrote a huge chunk of the code by hand. AI has assisted heavily with testing and validation, and sometimes with implementation and review.

The website is AI assisted too, but I edit both its design and prose heavily. Almost all copy on the main pages and in the documentation comes from me. AI helps keep the voice consistent and acts as a sounding board. I make the final decisions and remain responsible for everything that ships in Wax and on the website.