u/Healthy_Ship4930

Okay. After seven months, I'm back.

Seven months ago I started writing a Python interpreter from scratch in Rust, compiled to wasm (less than 200kb of bandwith). Edge Python is a sandboxed subset of Python that runs in the browser and the terminal, and code can't touch files or the network unless you allow it.

It started as a lexer and a simple stack VM, and over about 1,600 commits it grew a CLI, a package registry, snapshots, actors and a browser playground. It's just me building it.

Last week it was still 3x slower than CPython. I rewrote the VM this weekend on top of the SSA form I already had, and now the wasm build beats native CPython on loops.

	Edge (wasm)	CPython (native)
Integer loop	154 ms	232 ms
Float math	231 ms	307 ms
Dicts	372 ms	62 ms
Strings	196 ms	35 ms

The trick was a register VM, and Rust made it fit in wasm with NaN-boxed values and no runtime. It still loses on dicts and strings, so that's next.

Try to break my numbers :)

Website: https://edgepython.com/

GitHub: https://github.com/dylan-sutton-chavez/edge-python

When I started programming Edge Python more than six months ago, I was looking for a version of Python that weighed less than 200 kb so it could reach any device, sandboxed by design, built with browsers in mind, decoupled from the operating system and very fast.

Today the closest competitor would be MicroPython. However, it did not solve my real problems or the problems of the people who use the project.

• Managing async and blocking code on the event loop. MicroPython inherits CPython's blocking execution model, designed around the GIL. When I built Edge Python I put the events inside the virtual machine, and that lets you run any operation while handling thousands of connections without blocking the main thread or the worker's thread.
• MicroPython was not built for the web and neither was its stdlib. I have been working to get regex and every other dependency down to a few clean lines, crash free thanks to directed fuzzing.
• Edge Python guarantees parsing everything in linear time, in a single pass, while MicroPython does not. This came from avoiding a syntax tree, which makes programs parse faster.
• MicroPython crosses into JS through PyProxy. Edge Python avoids that entirely with an execution model decoupled from the host, they never have to interact directly.
• I recently added the ability to serialize entire programs, born from an issue. If a user closes the tab, the whole bytecode state gets serialized, stored in the browser cache, and when the user comes back execution continues from the exact same point.

That said, my intention was never to replace CPython and it never will be. It has a gigantic ecosystem and competing with it is not even a priority for me. What I want to enable is this.

• Anyone with business logic written in Python being able to run it on the client side.
• Running lightweight LLM logic on the client side, so you do not need expensive compute just to parse a CSV or do math.
• Building a framework to run lightweight machine learning models entirely on the user's side.

I am still working on all of this and, to be honest, I do not know how long it will take me to reach a real version to build a product around. I just want to say it has been an incredible process, and it has made me realize that with a compiler of barely under 20,000 lines I spend less and less time writing code and more time automating its stability with fuzzing and determinism.

Thanks! Any feedback or experience is appreciated. If you want to take a look, try the demo in the browser at edgepython.com and edit the code, the compiler is really fast. Try the CLI version too.

Hey! For the past four months I've been working on my compiler, and this week I've been refining my documentation using Nextra and embedding the compiler directly into the docs with editable React components, any feedback? :)

Downloading the compiler and component takes around 200ms, with the entire compiler weighing in at 200KB. It has also been fuzz tested across 16 cores for a total of 14 days of core-time without a single crash, using a seed corpus of 2200 inputs.

Try it out here: edgepython.com, any thoughts?

Hey everyone! Quick update on the fuzzer for edge python compiler :)

I wanted to share how I set up some infrastructure with Docker Compose to fuzz my compiler across multiple cores; what I did and what I learned because the implementation is very small but each decission tought me lot of time.

What's fuzzing? It's creating unexpected, or malformed input at a program to shake out bugs, crashes, and vulnerabilities. There are several approaches, but this is the one I went with.

I started by reusing the corpus from my unit tests

A little script turns the cases into a seed corpus (one file per program, so the fuzzer starts from inputs that already exercise most of the language) and a token dictionary of keywords, operators, and builtins. The fuzzer uses that dictionary to splice in real tokens defined by the lexer (here).

Next you pick a framework that fits your stack. My compiler is in Rust, so I used cargo-afl, the Rust tool for AFL++ (one of the best-known fuzzers out there; if you are in C or C++ the equivalent would be libFuzzer). From there you define a target: mine takes the raw input bytes as source code and runs them through lex, parse and VM (reference).

At that point you can already run a campaign on a single core. To actually scale it, I run everything in one container on an 8 core server (using docker). Inside that container the deploy script spins up one AFL instance per core and one "main", where they share the same output directory and sync their queues:

• https://github.com/dylan-sutton-chavez/edge-python/blob/main/compiler/fuzz-afl/Dockerfile
• https://github.com/dylan-sutton-chavez/edge-python/blob/main/compiler/fuzz-afl/compose.yml

It's a small setup and I'm sure there are best ways to do it, but it's a solid starting point if you've got a compiler of your own. In the early days I'd pull around 10 crashes in a single hour. Now that Ive fixed all the shallow bugs, it takes the fuzzer almost a full day to surface even one. Classic coverage saturation, and honestly a pretty satisfying sign of progress :)!

My implementation: https://github.com/dylan-sutton-chavez/edge-python/tree/main/compiler/fuzz-afl

Docs: https://edgepython.com/implementation/fuzzing

Couple days ago I included a fuzzer at edge-python, my less 200KB WASM Python compiler set, just to take a look what break. I Used cargo-afl, in a full run from the lexer and parse to VM on raw bytes.

First run: 346 "crashes" in five minutes. I panicked a bit (working four months on this and see that everyting breaks), then realized "American Fuzzy Lop" only flags actual signals, so since cargo AFL build turns panics into aborts, every one was a genuine an error, not noise.

Triaged them with a quick grep "panicked at" | sort | uniq -c... and basically all 346 were the same bug, where my string literal parser did &s[1..s.len()-1], and some edge cases included my crashes drop down.

Now is more stable, executing for 7 minutes now just find 9 crashes.

If anyone's done this on a lexer/parser/VM, what else is worth throwing at it?

To take a look to a bit more, I made a small documentation on my compiler docs edgepython.com

Hi! Software is never really done, but my compiler finally feels "finished," so I wanted to share it.

Its Edge Python, a sandboxed Python subset that compiles to one around 170KB WASM module and runs anywhere WASM does (browser, Cloudflare Workers, Wasmtime). 13,000 lines of no_std Rust. I always loved Python syntax and wanted to run it everywhere, safely, for the web.

Where in these 90 days the project got a sponsor, who is interested in running more than 7k lines of Python on the client side to save computation and reduce latency (zero codebase changes, just a packages.json file).

Here's a little bit about this compiler:

In CPython, await only works inside async def, so asyncness infects the whole call chain. I moved te scheduler into the VM instead. Coroutines are heap objects with fully snapshotted state, so a suspension point (sleep, receive, fetch) can fire from any function, even a plain def or module top level (all of this based on the wonderfull tokio package).

The VM snapshots the live frame, parks it on the enclosing coroutine, and walks frames inside-out on resume. try/except survives it.

def setup(label):
    sleep(0) # suspends inside an ordinary def, no async/await
    return f"ready:{label}"
print(setup("x")) # works at module top-level too

Structured concurrency (gather, with_timeout, run, cancel) ships as builtins, and the VM never reimplements an event loop: it parks a coro as WaitingHostCall(id) and lets the hosts loop (a browser Promise, Wasmtime) signal readiness.

With no host time hook,sleep() runs on a deterministic virtual clock, so concurrent code is instant and reproducible under test.

One more for this crowd: the bytecode is SSA-versioned with Phi at control-flow joins, which you rarely see in a stack VM this small. A hand-written Pratt parser emits it directly, no AST in between.

Demo: demo.edgepython.com
Docs: edgepython.com
GitHub: github.com/dylan-sutton-chavez/edge-python

Happy to go deep on the suspension mechanism or the inline caches. Feedback welcome.

Hi! Software is never really done, but my compiler finally feels "finished," so I wanted to share it.

Its Edge Python, a sandboxed Python subset that compiles to one around 170KB WASM module and runs anywhere WASM does (browser, Cloudflare Workers, Wasmtime). 13,000 lines of no_std Rust. I always loved Python syntax and wanted to run it everywhere, safely, for the web.

Otherwise, in CPython, await only works inside async def, so asyncness infects the whole call chain. I moved the scheduler into the VM instead. Coroutines are heap objects with fully snapshotted state, so a suspension point (sleep, receive, fetch) can fire from any function, even a plain def or module top level.

The VM snapshots the live frame, parks it on the enclosing coroutine, and walks frames inside-out on resume. try/except survives it.

def setup(label):
    sleep(0) # suspends inside an ordinary def, no async/await
    return f"ready:{label}"
print(setup("x")) # works at module top-level too

Structured concurrency (gather, with_timeout, run, cancel) ships as builtins, and the VM never reimplements an event loop: it parks a coro as WaitingHostCall(id) and lets the hosts loop (a browser Promise, Wasmtime) signal readiness.

With no host time hook,sleep() runs on a deterministic virtual clock, so concurrent code is instant and reproducible under test.

One more for this crowd: the bytecode is SSA-versioned with Phi at control-flow joins, which you rarely see in a stack VM this small. A hand-written Pratt parser emits it directly, no AST in between.

Demo: demo.edgepython.com - Docs: edgepython.com - GitHub: github.com/dylan-sutton-chavez/edge-python

Happy to go deep on the suspension mechanism or the inline caches. Feedback welcome.

Month four building my own embedded Python runtime in Rust 145kb release, runs in-browser via WASM. demo.

Tested it across a bunch of hosts this week and hit something I can't find documented anywhere: on machines with virtualization-based security enabled (HVCI/VBS default on every Copilot+ PC with Snapdragon X Elite), every memory.grow call in WASM costs ~0.2ms. Not microseconds. The hypervisor validates EPT page mappings before handing them to V8, and that round-trip is the whole cost.

My demo does ~3,000 allocs per run. I was using LeakingPageAllocator from lol_alloc the one in every README which calls memory.grow(1) on every alloc. 3,000 × 0.2ms = ~600ms of pure grow overhead before a single line of Python executes. Edge on Snapdragon X Elite: ~5s to feel responsive. Same WASM on Linux/macOS: under 50ms. 100x cold-start difference, same module, same V8.

Fix was a one-line swap to LeakingAllocator a real bump pointer that grabs pages in bulk and bumps within them. ~50 grows instead of 3,000. Cold start dropped to ~10ms.

#[global_allocator]
static A: AssumeSingleThreaded<LeakingAllocator> =
    unsafe { AssumeSingleThreaded::new(LeakingAllocator::new()) };

The leak is fine here the JS host throws away the WASM instance between runs, so working set is bounded and the OS reclaims everything on teardown.

What I want to know: is anyone else benchmarking WASM cold-start on Copilot+ PCs? The default allocator everyone copies from lol_alloc's README is genuinely the worst choice for these machines, and Microsoft is pushing them hard. If you've shipped WASM in Edge on a Snapdragon X Elite and measured, what did you see? Is this a lol_alloc gotcha or a general "VBS makes memory.grow expensive" thing?

Happy to answer questions about the runtime parser, VM, GC, plugin ABI, whatever.