Node.js creator Ryan Dahl is sacrificing a battle to win the war … for server-side computing and allowing Node-replacement Deno to fall by the wayside. Last week, Cloudflare announced that it had purchased Dahl’s company Deno, which was built around an open source server-side JavaScript runtime of the same name that he created, to compete with the Node.js runtime, which he also created. Nonetheless, Deno has no future at Cloudflare, which will maintain the runtime for another year before ending its development. That’s OK with Dahl. "I am now of the opinion that if you're choosing Node.js for building servers, you’re doing it wrong," Dahl told The Register. For Cloudflare, the Deno buy is an acquihire for Dahl and 12 of his Deno colleagues, who will work to build out Cloudflare’s Workers platform, expanding it for potential open-source use. He feels this approach is the way to go. “Right now, every other server is really operating at the Linux VM layer. That is not what Cloudflare Workers are," he said. The unstoppable force of Node.js Dahl’s Node.js, which he presented to the world in 2009, sparked a revolution in Web application architecture. He was fed up with the Apache web server hogging all the memory. Using the Google V8 JavaScript engine, Node not only could execute JavaScript code on the server, but it could concurrently serve thousands of requests per second with a fraction of the memory required by the traditional choice of the time, Apache Web server. Today, Node powers about 30 million websites worldwide. With 130 million downloads, it probably runs a lot more internal operations as well. The ever-fickle Dahl first debuted Deno in 2018 as a rewrite of Node. The name ‘Deno’ is an anagram of Node, and it was Dahl’s attempt to fix everything he felt he got wrong with Node – built-in fetch, a permission model, native TypeScript support et al. Sequoia backed Dahl’s company for $21 million in 2022, and as of August, Deno amassed 400,000 monthly users. Nonetheless, Node’s gravity proved too heavy for Deno to achieve escape velocity. “What we found over years of working on Deno is that you can't really deviate from Node.js very much," Dahl told The Register. "As we continued to try to get adoption for Deno, we found we had to essentially backpedal on some of the original promises and become more Node compatible over time, and that left us as a kind of an alternative Node.js implementation.” Going forward, Cloudflare will supply Deno with bug fixes and security patches for the next year, while Dahl looks for a new home for the MIT-licensed open source project (the OpenJS Foundation perhaps?). The new way: distributed micro-servers In August, Dahl released an entirely new project, called celld, which was an open source implementation of Cloudflare’s Durable Objects. He was fascinated by the technology, originally created by Kenton Varda. “A primitive this good deserves to run anywhere,” the celld page stated. Durable Objects allow developers to build stateful, real-time distributed applications. Unlike Node or Deno, the resulting application doesn’t require a dedicated runtime environment. It runs on Cloudflare’s serverless Workers runtime, which executes code inside Google JavaScript V8 isolates — a lightweight sandbox running within a single OS process. Individual instances of the application can be spun up at an edge location closest to the user. Each Durable Object instance acts as a single-threaded micro-server with a unique global ID and its own co-located storage, where user data for the session is stored in its own dedicated copy of SQLite. Durable Objects “is kind of the perfect distributed systems abstraction,” Dahl said. The drawback of Durable Objects for Dahl was that it was hard-wired into Cloudflare’s infrastructure. He created celld as an implementation that could be hosted anywhere, not just on Cloudflare. As it turns out, Cloudflare had similar aspirations. In 2022, the company had open-sourced a version of the Workers runtime, called workerd, but the release was more geared towards developer testing. The company never got around to making Workers fully self hosting, much less giving it the chops to maintain distributed state, a power Dahl gave to celld. So the mission for Dahl's team is to merge the work of celld with workerd for a stand-alone JavaScript/WebAssembly runtime, while integrating it with Workers and Durable Objects as much as possible. (celld is also going bye-bye.) Such a technology could be yet another revolutionary turn for server-side JavaScript, offering a runtime that would require only 300 KB of memory per instance, rather than the hundreds of megabytes now required for Node/Deno. Such savings could quickly add up for a cloud provider, especially one serving the voracious agentic market. But until we see the fruits of Dahl’s team, the market for independent runtimes will be squeezed, what with the absence of Deno and Anthropic’s recent acquisition (and rewriting) of Bun. Now, Dahl’s first creation, the mighty Node, will have to go it alone.®
With some extra tokens to burn, developer and popular YouTuber Theo Browne used AI agents to port Microsoft's TypeScript compiler to Rust, just to see if it could be done. Not only did he produce a working implementation, but the resulting code could also pave the way for more memory-efficient environments for AI agents. Browne claims his Rust port runs twice as fast as Microsoft's official Go-based TypeScript rewrite (v7) released earlier this year and 12.5 times as fast as the previous version of TypeScript (v6) – not bad work considering he says he hasn’t even inspected the code. TS_Rust is a project that would have been impractical even earlier this year, Browne noted in a video presentation. But models are developing so quickly that heretofore unimaginable tasks are now possible. The resulting Rust-based TypeScript also opens the possibility of using Google’s V8 engine as a less-memory-intensive alternative for running agentic workloads written in TypeScript, an approach that would be unfeasible using Microsoft’s Go implementation of TypeScript, Browne argued. A job that shouldn’t be possible Browne’s original idea was to burn his excess tokens by tackling a project so large that it couldn’t possibly be finished, just to see how far the latest models could get. The agentic rewrite involved porting the TypeScript compiler, type checker, and language server, which provides features such as error checking and code completion in editors. He burned more than $400,000 worth of API-equivalent tokens using OpenAI's GPT-5.6 Sol and GPT-6 Astra, which reached roughly 84 percent compatibility before the models struggled to complete the remaining work. When Anthropic released Claude Opus 5.5 last month, he revisited the idea. To his surprise, the new model produced a working implementation, consuming about $24,000 worth of API-equivalent tokens through Browne's Claude subscriptions. The resulting implementation passed the TypeScript conformance tests with nearly 100 percent accuracy. Perhaps this unexpected success was due to Claude 5.5 being a more muscular model, Browne reasoned. But Claude was also clever enough to change its strategy to get a head start. Rather than attempting a direct translation from JavaScript to Rust, the model ported Microsoft's Go implementation of TypeScript to Rust, copying a few bugs from the original along the way. Browne only learned that Claude did this after someone else pointed it out. “Writing all of TypeScript from JS to Rust would not have been viable,” he said in the video. “The Microsoft team went through every line of code in TypeScript, ported it to Go, and then started refining it to make it better and faster in Go. My agents did the same thing from the Go version to Rust." TS_Rust is one of several recent projects that used LLMs to rewrite some software in Rust. Microsoft itself recently rewrote the Copilot runtime in Rust. That project cost the 'softies about $120,000 in AI coins. Google, with the release of its Gemini 4 Argon model, is also using AI agents to port several major C/C++ codebases (RE2, libgav1, and parts of Fuchsia's Zircon kernel) to Rust. V8-powered agents Beyond the novelty factor, Browne’s own version of TypeScript may ultimately provide a practical benefit by eliminating the need for agents to deploy relatively heavy agentic workspaces such as virtual machines and Docker containers. It’s a job even Microsoft’s own official Go implementation couldn’t do as effectively, he argued. This work, should someone see it through, would be timely. Browne argued that with more powerful models on the horizon, inference costs are plummeting exponentially, so much so that the underlying compute costs needed to support developer environments will soon be the most expensive part of the job. With a Rust-based TypeScript compiler, some agentic workloads could potentially run within Google's V8 engine, instead of requiring a full container or VM. Cloudflare, for instance, already isolates multiple user environments using the Google V8 JavaScript runtime, thereby saving hundreds of megabytes per customer environment. TypeScript itself, stripped of its type annotations, runs cleanly within V8, but Microsoft’s Go-based TypeScript compiler is not a good fit because Go's garbage collector must be bundled into the runtime using WebAssembly – no easy task. But Rust doesn’t need a garbage collector, so it compiles more efficiently with WebAssembly. A lightweight agentic environment could, in theory, run within V8 using TS_Rust and an in-memory shell environment such as Vercel's Just Bash, potentially reducing costs compared with running the same workloads in a VM. As for Browne, he remains bullish on AI and software engineering. “These types of YOLO projects should not be viable at all. Like [it] shouldn't even be able to pass the tests, much less actually work as a drop-in replacement for TypeScript,” he said. ®
After a week’s delay, the new version of Python, v3.15, has been released. With it comes a proper profiler, an experimental just-in-time compiler, and a tightening of dictionary structures. It also offers a time-saving Lazy Import option for programs to not load modules until needed, the implementation of which ironically halted this release until a few last-minute regressions were sorted. But of all these new delicacies spread before the Pythonistas, the data wranglers of the bunch may most appreciate default UTF-8 support across all platforms. And when we say “all platforms,” we’re really just throwing shade at Windows (as usual). Python has defaulted to macOS and Linux Python environments for some time now. It’s a small but important update. About half of all Python developers use the language for processing and analyzing data, and about 58 percent of Python users build on Windows, according to various Python Software Foundation surveys. Party crashers Earlier versions of Python defaulted to the host system's locale encoding. This led to much consternation for Windows developers whose scripts opened UTF-8-encoded data sets, only to have non-ASCII characters corrupt or crash the program. Culprits could be as innocuous as a smart quote or a fancy apostrophe. Managed by The Unicode Consortium, with the help of the IETF and ISO, UTF-8 is an 8-bit binary encoding of the Unicode catalog of all the world’s written symbols. ASCII offered only 128 characters to cover the world’s knowledge, but UTF-8 provides over 1.1 million slots, which is plenty of room for smart quotes, emojis, musical and math notations, all the Chinese dialects, and even a few extinct languages (for research purposes). There’s also UTF-16 and UTF-32, but UTF-8’s combination of efficiency and inclusiveness made it the default for the Web and most modern operating systems. By the time Python Enhancement Proposal 681 was proposed in 2022 to make UTF-8 the preferred encoding, the language was already behind the times. That year, Java settled into UTF-8 with JDK 18, and Ruby 3.0 defaulted to the encoding scheme in 2020. Today all the cool languages and runtimes pledge allegiance to UTF-8, including Rust, Go, and Node.js (JavaScript itself prefers UTF-16 for internal encoding). Most code editors, from Visual Studio Code to Windows Notepad, prefer UTF-8. Data sharing and configuration formats such as JSON, TOML, and YAML all require 8-bit encodings. Python had long understood UTF-8, but programmers had to put a flag in their code alerting the language to use it – if they knew they had to do so at all. Many didn’t and were left scratching their heads over why their data processing scripts worked just fine on MacOS or Linux but then would flame out on Windows (or some other obscure system that defaulted to a C/POSIX locale). Programmers love puzzles To acquaint developers with the new aspects of the language, longtime Python programmer Barry Warsaw (AKA “Uncle Barry”) created a terminal-based adventure game called “whatsnewt” that offers 18 puzzles, each one built on a new feature found in Python 3.15, including a puzzle for UTF-8 support, “The Encoding Tower of Babel.” Once you've downloaded Python 3.15, do a “pip install whatsnewt” and then run the game on the Python command line. It even works on Windows, we hear. ®
Anthropic's Claude models have been emitting so much code that the company's coding infrastructure hasn't been able to keep up. It's a symptom of the AI coding imperative and all-you-can-eat inference. Microsoft's GitHub in April published a blog post attributing recent availability problems to the exponential growth in pull requests and commits. The code flood has been noted by academic researchers, among others. For Anthropic, writing code is no longer a productivity bottleneck. Instead, the problem is managing the code after it's written, via source control, the build system, and continuous integration. "In May 2026, Anthropic averaged around 2,500 code changes merged per day; as of September, we merged over 30,000 per day," the biz said in a blog post on Tuesday. "We don’t expect this rate of growth to slow down anytime soon; the latent demand for merging code is practically infinite, and every bottleneck we remove immediately leads to a further increase in the amount of code we produce." After several months of model prompting and five months of migration, the result is a homemade version control system called Scion, a monorepo scheme that sounds a bit like Subversion, Apache's centralized version control system. Anthropic is not the first organization to look beyond Git's distributed architecture toward centralized source control. Google uses Piper, a monorepo system (along with Gerrit for Git-based code reviews). Microsoft has Virtual File System for Git, formerly GVFS, to help overcome some of the scaling issues with Git. Meta has Sapling. But as the AI biz notes, Claude's code writing ability both created the situation and offered a way out through the creation of scalable code infrastructure tools – in addition to Scion, Claude helped conjure Antique (a code review interface), a code search tool, and a source control IAM system. The decentralized approach embodied by Git is the right one for most code repos, according to Anthropic. But the company's main branch weighs in at about 100 GB, with a compressed working copy at more than a quarter of that. "We perform on the order of 25 million code checkouts per day for CI, before counting developer environments, agent sandboxes, and research jobs," Anthropic said. "Fetched naively, that would be over 600 PB of git traffic per day." Even with the tools Git provides for working with portions of a codebase, Anthropic says operations proved challenging. Scion has been designed to meet the needs of AI agents, so the client leaves much of the work to the server; the source control queries are exposed via API so internal tools can respond without needing a local repo, and there's less synchronization but more need for server speed. "In Scion, the unit of work is a 'changeset,' an entry in a write-ahead log," Anthropic explains. "A changeset stores most of what you’d expect from a commit in git. But where a git commit stores a pointer to the tree, a changeset stores a list of the files that changed relative to its first parent, along with content-addressed pointers to the compressed file contents in blob storage." Work on Scion started in January, and when Claude Mythos Preview became available internally, Anthropic's code coaxers told the model to rewrite an early Git-to-Scion ingestion pipeline. The much-hyped model produced a version that used 20 times less memory and ran four times as fast. When cost is no object thanks to ample venture funding, that sort of token spending just makes sense. Anthropic's Claude jockeys appear to be taking their obsolescence in stride. According to the AI biz, company developers who worked on Scion agree that Claude writes better code than they do. But they still possess a higher-level understanding that gives them a role as naysayers. "Very often, we found that the role of the engineers was to tell Claude 'no,'" Anthropic said. "Agents will sometimes violate core system constraints to satisfy a pattern that should never have been allowed in the first place." "Just say no." As a slogan, it's timeless. And it's never been more relevant. Anthropic says its bespoke system isn't right for general use. There will be no open source release. Nonetheless, the company contends that its own code scaling problems will become commonplace in other organizations over the next few months, so it wanted to share its approach – having ample funding to pay for writing custom infrastructure tools. ®