Three projects shipped compiler or toolchain work between October 26 and 27: Pharo 14, the AI-written Goose language, and Cloudflare's tsrs. Two of the three were substantially written by an AI model. The third added a RISC-V JIT to a Smalltalk-derived live environment. The coincidence probably doesn't mean much, but each release has details worth stealing time for.
tsrs is the one most people can use today
Cloudflare built tsrs with VoidZero and Max Schwenk of Owner.com, incubating it inside the Oxc toolchain and working with the TypeScript team. Cloudflare says it is not a fork and that Microsoft's team keeps full control over language design. That distinction matters if you have been burned by a compiler fork drifting from upstream semantics.
The claimed numbers, measured against TypeScript 7.0 at the same number of checker workers: up to 8x faster type checking, about 70% less memory. Those are Cloudflare's own benchmarks, which is the usual caveat. The comparison is at least controlled, since both sides run with an equal worker count instead of letting the Rust version eat every core.
Trying it is a two-liner:
npm install -D tsrs
npx tsrs -p . --noEmit
It reads an existing tsconfig, so migration on a branch is cheap. Rust also gets you @tsrs/wasm, which means checks can run in a browser or on Workers without pulling a garbage collector into the bundle the way a Go binary would.
Two things stop me from recommending it in CI. First, it ships without a watch mode or a language server, --init and --showConfig are unsupported, and diagnostic order can differ from tsc. Second, and more annoying, tsrs tracks TypeScript 7. If your repo is on TypeScript 5 or 6, you have to move to Microsoft's Go port (tsgo) first, then swap. That is a two-step migration for a tool that is still experimental. Cloudflare is also merging Theo Browne's tsc-rs into tsrs and adding language server and content mapper support, so the surface area will change under you.
My read: run it as a second check on a monorepo where type checking is the slow part of the loop. Keep tsc as the authority until the language server lands.
Goose solves memory management by removing the heap
Wouter van Oortmerssen's Goose is a systems language implemented almost entirely with an AI model, in this case Claude Fable. He had the concept before; the model wrote the compiler, docs, examples, and tests, and the back-and-forth refined the design. The compiler emits C, which is a smart shortcut: you get clang and gcc's optimizers for free and don't have to write a backend.
The memory model is the interesting part. No heap, no garbage collector, no lifetime annotations. Data lives on stacks, stored compactly and sequentially, so a nested object doesn't get its own allocation. When a scope ends, memory is reclaimed by moving the stack pointer. The compiler rejects code where a reference can outlive the object it points at. There is no unsafe keyword at all.
The project published 16 benchmarks. On its own tests, Goose is about 3.5x faster than idiomatic C++, 1.2x to 1.3x faster than hand-optimized C++, 1.13x to 1.19x faster than the fastest safe Rust, and uses 1.25x to 1.95x less memory. Publishing the tests where it loses is a good sign. Self-reported benchmarks from the author of a new language are still self-reported benchmarks.
The restrictions tell you more than the numbers. Variable-size element arrays can't be indexed arbitrarily. Recursive functions can't hold growing structures across recursive calls. There are no function pointers and no dynamic method dispatch in the usual sense. Those are not small gaps; they rule out most of what people actually write in systems languages. Goose is a design experiment that produced a working compiler, not a C++ replacement you can port a game engine to this quarter.
Still, the constraint of "no lifetimes to annotate, and no unsafe escape hatch" is the right problem to attack. Rust's borrow checker is correct and exhausting. Whether a stack-discipline language can cover enough real programs is the open question, and now there is a compiler to test it with rather than a blog post.
Pharo 14 ships a VM overhaul and a RISC-V JIT
Pharo 14 landed October 26, the first release under a new fall schedule instead of the old spring one. It integrates 978 pull requests and closes 616 issues since Pharo 13, under the MIT license.
The tooling changes are extensive. Mission Control and Pulse (which replaces Spotter) join a reworked Method Browser and a rewritten Settings Browser. Epicea and ProfStef moved into NewTools, continuing the migration to the Spec tooling stack. Refactoring commands sit behind a driver-based architecture and a unified command registry. Command-line testing and a command-line debugger are now included, along with Sindarin script tooling for headless workflows.
The VM work is where I'd look first. Frame and stack management are unified, RISC-V gets a JIT, and memory management added direct old-space allocation plus GC improvements. The team also worked on Slang and C compilation and rebuilt the cross-platform build infrastructure.
Pharo's pitch is that there is no compile and deploy step: you edit, test, debug, and run in the same image, and the debugger lets you restart a method mid-execution and define new methods on the fly. If you have only worked in languages with a build step, spending an afternoon in a live environment changes how you think about the edit-test loop. RISC-V JIT support means the project can follow hardware that is increasingly relevant outside x86 and Arm.
What to do with this
If TypeScript type checking is your bottleneck, put tsrs on a branch this week and time it against your real tsconfig. Just don't wire it into CI until it has a watch mode and a language server. Read the Goose benchmarks and, more importantly, the limitations section, because the limitation on recursive data structures is the one that decides whether the approach generalizes. And if you have never used Pharo, the download is free and the tutorial is short; the interesting part is not the syntax, it is working without a deploy step.