"Cloudflare has acquired Deno, the company behind the [server-side] JavaScript and TypeScript runtime created by Ryan Dahl, the inventor of Node.js," Forbes reported last week. But Deno "has no future at Cloudflare, which will maintain the runtime for another year before ending its development," writes The Register. "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." It all started with his team's work on the platform Deno Deploy, "We wanted to make running applications as straightforward as possible," Dahl wrote on the official Deno blog. "But building and operating Deploy also showed us how much complexity remained underneath that developer experience. I wanted to simplify that layer, too." This led to celld. Building on the Cloudflare Workers programming model, celld lets developers build distributed applications from the start while making the system simple to operate. What excites me greatly is that the scaling is built into the programming model, rather than infrastructure each app has to assemble itself.... We want to make this programming model the default way to build servers, whether you run on Cloudflare's network or your own infrastructure. Joining also means choosing where to focus our effort... Deno will remain open source, and we welcome others who want to continue its development. Deno Deploy will continue operating for six months before shutting down. We will provide migration support for paying customers moving to Cloudflare Workers. [Deno's JSR package registry for JavaScript and TypeScript] will continue operating, with its infrastructure moving to Cloudflare. Forbes argues that this acquisition of Deno "turns a long-standing objection to Cloudflare Workers, the claim that applications built on it cannot easily leave, into a selling point." For CIOs evaluating serverless and edge platforms, portability now has a concrete answer... Released in August, [celld] is a single Rust binary that runs Workers and Durable Objects across many machines, with object storage as its only external dependency. Operators run multiple celld instances against one storage bucket, and the software handles placement, routing and persistence. Dahl and Belder will now lead an effort to merge celld into workerd and make self-hosting a supported way to run Workers applications. With this, customers can build an application on Cloudflare's network and move it to a private data center without rewriting it. "With Deno, we improved the experience of writing JavaScript," Dahl argues on the Cloudflare blog, "but we didn't fundamentally change what developers had to assemble around the runtime. The bigger problems are around networked applications: distributing computation, coordinating state, data storage in general, and autoscaling to meet demand..." Could the programming model make partitioning across machines part of the design from the start? The solution clicked into focus when I read about Cloudflare's Durable Objects. It provided a very powerful abstraction: the distributed singleton with a SQLite database. Each Durable Object is like a small, individually addressable server with its own relational database. Its JavaScript execution is single-threaded (which is easy to reason about), it handles WebSockets, and its local SQLite database can be accessed synchronously. By building a chat application using one Durable Object per channel, you have sharded your data and WebSocket connections, and thus made your application scalable... What excites me is the leverage this model gives developers: compute, relational databases, queues, and real-time communication primitives designed for applications distributed across machines. Now Dahl and 12 of his Deno colleagues "will work to build out Cloudflare's Workers platform," explains The Register, "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 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. Dahl's worked could bring "yet another revolutionary turn for server-side JavaScript," the article argues, "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." And as Dahl wrote on the Deno blog, "The need for better abstractions is especially acute with AI. Durable Objects bring together capabilities that are particularly useful for agent harnesses: inexpensive, serverless execution, persistent state, WebSockets, and a high-level JavaScript interface. This is what I'm most excited to explore and why celld focuses on Durable Objects."

Read more of this story at Slashdot.

Ars Technica reports: Half a year after Iranian drone strikes knocked out multiple Amazon data centers, the US tech company has acknowledged the permanent loss of some customer data that was hosted in Bahrain and the United Arab Emirates. Amazon Web Services was "unable to restore access to the resources and data" hosted in some of the war-damaged data centers, according to an AWS dashboard update posted on September 15. The development was first reported by Reuters and suggests that the Iranian strikes inflicted catastrophic damage on the data centers. Customer data was irretrievably lost in one of three AWS availability zones in the United Arab Emirates region, specifically the mec1-az2 availability zone. Each availability zone is serviced by one or more Amazon data centers. The company is still working on "recovering regional resources" and restoring resources hosted in the other two availability zones in the United Arab Emirates... But the destruction was apparently even more widespread for the data centers in the Bahrain region, because Amazon said it was unable to restore access to resources and data across all three availability zones there. "The damage to our infrastructure spanned multiple Availability Zones and exceeded what our regional and multi-AZ services are designed to withstand," the AWS update said. The company had already suspended customer billing in the affected AWS regions in Bahrain and the United Arab Emirates and has spent the past six months attempting to restore normal operations... [When the war began] AWS immediately urged customers to migrate resources to other cloud regions and use remote backups to restore any "inaccessible resources." The cloud service also reportedly issued $150 million in customer credits following the initial Iranian strikes in March.

Read more of this story at Slashdot.