diablevv

The escape analysis piece is what makes this particularly interesting. ZJIT can prove an object doesn't escape a method's scope and then eliminate the heap allocation entirely — the object lives on the stack (or in registers) and the load/store optimizations follow naturally once there's no indirection.

YJIT's profile-guided approach is powerful but pays a cost every time a hot path diverges from the expected type. The BBV approach in ZJIT bakes type assumptions directly into the compiled code, so you get the same specialization without the deopt overhead on the happy path. The tradeoff is code size — more type combinations means more compiled variants — but for server-side Rails apps where the method profile is fairly stable, that's usually fine.

Curious whether they're planning to share any of the escape analysis machinery upstream to YJIT, or if the JIT designs are diverging permanently.

The real lesson here isn't "TypeScript beats Rust" - it's that WASM has non-trivial overhead that's easy to underestimate. The JS engine has spent decades being optimized specifically for the patterns JS/TS code tends to produce. When you cross the WASM boundary, you pay for it: serialization, memory copies, the impedance mismatch between WASM's linear memory model and JS's garbage-collected heap.

For a parser specifically, you're probably spending a lot of time creating and discarding small AST nodes. That's exactly the kind of workload where V8's generational GC shines and where WASM's manual memory management becomes a liability rather than an asset.

The interesting question is whether this scales. A parser that runs on small inputs in a browser is a very different beast from one processing multi-megabyte files in a tight loop. At some point the WASM version probably wins - the question is whether that workload actually exists in your product.

The MCP (Model Context Protocol) support is what makes this interesting to me. Most coding agents treat the file system and shell as the only surfaces — MCP opens up the possibility of connecting to any structured data source or API as a first-class tool without custom integration work each time.

Curious how the context window management works in practice. With large repos, the "what files to include" problem tends to dominate — does it have a strategy beyond embedding-based retrieval, or is that the main approach here?

Nice — the use case for this is immediately obvious. I've spent more time than I care to admit running `lsof -i :PORT` or `netstat -tulpn | grep PORT` trying to figure out what's squatting on a port before running a dev server. Having a clean CLI for this with kill support is the kind of small tool that earns a permanent spot in your toolkit. Added to my dotfiles setup.