# Virtual machine in Rust type system **URL:** \ **Category:** tutorials\ **Created:** [March 3, 2026, 11:49am UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671 "2026-03-03T11:49:01Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![AureaNoire](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/aureanoire/32/51642_2.png) [@AureaNoire](https://users.rust-lang.org/u/AureaNoire)\ **Post date:** [March 3, 2026, 11:49am UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/1 "2026-03-03T11:49:01Z")
Hello! I wrote a virtual machine in the Rust type system! (Why not.) This is a follow-up to [a CTF challenge](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=ea2249e6fdad3319a4c3b62084b66418) I wrote. It is a small proof-of-concept virtual machine embedded in the Rust type system, which uses trait resolution and in particular associated types to "execute" a program, represented as a type, to its final state. (The "execution" happens during Rust compilation.) The VM architecture is simple: two 8-bit registers, a stack, a small number of instructions, including conditional control flow. However, other than patience and hitting the recursion limits, more useful/realistic architectures could be embedded as well. I wrote a blog post that goes into more depth about how this was developed and how it all works: [thenet / Virtual machine in Rust type resolution](https://www.thenet.sk/blog0011) The repository with all the (cleaned-up) code is here: [GitHub - Aurel300/type-system-vm: VM in the Rust type system.](https://github.com/Aurel300/type-system-vm) ---
**Author:** ![threefold3](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/threefold3/32/32050_2.png) [@threefold3](https://users.rust-lang.org/u/threefold3)\ **Post date:** [March 3, 2026, 12:43pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/2 "2026-03-03T12:43:42Z")
Nice read! Rust unhinged got to the next level, and now rust has an insane performance stress test for its trait resolver. 😁 ---
**Author:** ![ZiCog](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/zicog/32/12216_2.png) [@ZiCog](https://users.rust-lang.org/u/ZiCog)\ **Post date:** [March 3, 2026, 8:04pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/3 "2026-03-03T20:04:11Z")
Amazing. Totally nuts but brilliant. Clearly I have some things to learn about Rust from this... ---
**Author:** ![ProgramCrafter](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/programcrafter/32/45916_2.png) [@ProgramCrafter](https://users.rust-lang.org/u/ProgramCrafter)\ **Post date:** [March 3, 2026, 9:51pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/4 "2026-03-03T21:51:59Z")
So have you ran across trait resolver bugs like the one in `cve-rs`? Associated types look a bit scary, on a bug they could unify to anything. ---
**Author:** ![simonbuchan](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/simonbuchan/32/19939_2.png) [@simonbuchan](https://users.rust-lang.org/u/simonbuchan)\ **Post date:** [March 3, 2026, 10:26pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/5 "2026-03-03T22:26:19Z")
I assume the end state would be [running doom](https://github.com/MichiganTypeScript/typescript-types-only-wasm-runtime) It took typescript 177TB of types, so maybe stock up on RAM. ---
**Author:** ![AureaNoire](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/aureanoire/32/51642_2.png) [@AureaNoire](https://users.rust-lang.org/u/AureaNoire)\ **Post date:** [March 3, 2026, 10:55pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/6 "2026-03-03T22:55:14Z")
No, I didn't really run into (scary) bugs. The issue that was solved with `-Znext-solver` was the result of compiler checking some `impl` blocks too eagerly, even though they were not actually candidates for selection (if I understand it correctly). This is technically fine: it just disallows some programs that should actually type check, i.e., it is a completeness issue, not a soundness one. Apart from that I thought I found a problem that caused the compiler to hang indefinitely, but as I note in the blog post, I think it's actually just that the time to perform the error reporting scales really badly with the number of (related) `impl` blocks. Also `cve-rs` does not seem to be related to trait resolution, right? ---
**Author:** ![RustyYato](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/rustyyato/32/49247_2.png) [@RustyYato](https://users.rust-lang.org/u/RustyYato)\ **Post date:** [March 4, 2026, 4:03pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/7 "2026-03-04T16:03:02Z")
You can control order of evaluation of associated types by using GATs For example, I used it to great effect to embed lambda calculus into the type system. This way I could iteratively reduce until I got a normal form, and stop. Instead of the Rust type system just unfolding infinitely. > ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex019/user_avatar/users.rust-lang.org/system/32/51372_2.png) [@system](https://users.rust-lang.org/u/system)\ **Post date:** [June 2, 2026, 4:03pm UTC](https://users.rust-lang.org/t/virtual-machine-in-rust-type-system/138671/8 "2026-06-02T16:03:19Z")
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.