I’m happy if this means Deno is able to get a second impulse. I use Deno daily and while it’s true that it’s in this weird position where it’s not sexy like bun or enterprise-y like node, it has a great developer experience. a no-surprises runtime that does a lot of interesting things the right way (like compile to desktop to a browser-less webgpu runtime), the vscode extension is flawless and overall the perfect balance of batteries included without bloat.
of course i’m only talking about deno, the technology not deno, the cloud service.
The majority of the last year's development has been via LLM. I don't think anyone is going to want to fork that when they can just tell an LLM to do whatever and get the same result
The fact that Deno development is being suspended doesn't mean the community can't step in. The Deno runtime is licensed under MIT. Such forks might be impulse to grow even further.
> I’m happy if this means Deno is able to get a second impulse
Bad news, sorry, the article says:
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Sounds like Celld will live on within workerd, Deno is over.
> I’m happy if this means Deno is able to get a second impulse.
From TFA: We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So unless someone else picks up development, Deno will no longer be supported.
Fuck me! We’re going to have to start our migration as soon as possible. I knew we were in a precarious spot after the layoffs, but this is a truly sad outcome.
Fundamentally this acquisition is not about Deno the open source project. It’s about buying an amazing team that has built a self-hosted version of Cloudflare Workers that actually doesn’t suck. And that is all about commoditizing the complement.
Deno built celld, which implements the Workers and Durable Objects programming model with self-hosting in mind. Cloudflare says its own distributed infrastructure is too complicated for straightforward self-hosting, and it hadn’t successfully solved that problem. For customers who might be reluctant to commit to being locked in to Cloudflare’s infrastructure, having a rock solid self-hosted alternative reduces that reluctance.
I'm still learning the project, but from what I read so far, there is no need.
`celld` is not tied to Deno. `celld` handles the interface with v8 directly via `rusty_v8`, which they mention will keep being supported. So, Node, Deno and celld all share the same engine already.
What we will probably see in the next few months is a major version of `workerd` which is a rebranded celld with better Cloudflare support. And then a bunch of improvements in further versions.
While I think `celld` is a nicer name it makes sense to keep the official Cloudflare product/solution as `workerd`.
I hope the developer experience gets closer to Deno, I'm no fan of setting up all the required Node tooling for proper TypeScript support. I really like Deno. RIP
workerd is really far from production-ready Workers replacement, and seems to be very specifically scoped in such a way that essential parts of why Cloudflare dares to run it are not included in the bundle.
My best guess is you're talking about sandboxing, specifically how we defend ourselves against malicious tenants. Indeed, a lot of how we defend against that is not in workerd, and fundamentally can't be, because it's more than just some code, it's a process requiring active management.
However, you only need that if you have untrusted tenants.
If you are using workerd to self-host your own applications on non-Cloudflare infrastructure, then this isn't a concern for you. You don't have untrusted tenants.
If you are hosting untrusted tenants, then you can put workerd in a micro VM, the same as you'd do with any other popular runtime.
My best guess is that you are suggesting that we should open source our multi-tenant hosting technology, along with workerd.
But this doesn't make sense. No popular JavaScript runtime includes multi-tenant hosting technology. Multi-tenant hosting is the responsibility of the hosting provider. workerd is compatible with other providers' multi-tenant hosting approaches. You do not need our specific technology in order to run Workers apps on other hosting providers, and in fact would not even be particularly useful for that purpose.
US level anti-trust laws don't touch on a lot of anti-competitive behavior, mostly specifically it almost solely concerns just trusts and monopolies. I don't think I've heard of a court case ever before simply on the death of a product.
But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.
(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)
(There might be something the state of California could do, but I don't know how much they want to get involved.)
US v. Paramount separated movie studios from movie theaters.
Sumner Redstone came from a movie theater family and formed modern Paramount by buying Viacom (which was spun out of CBS due to antitrust), Paramount, and then later CBS itself. He was able to buy Paramount as a cinema owner because the government abandoned the rule that you couldn't own both the studio and the theater in the 80s.
The corporate history of Hollywood is long and complicated. Skydance is obviously a big topic this month, but Paramount was owned by the Redstone family's National Amusements theater for as long as many of the adults on this site have been alive.
National Amusements wasn't considered an official breach of the Paramount decree because it was "the other around", a theater chain owning a studio rather than a studio owning the theaters. It also got a lot of weird exceptions because National Amusements was entirely private at the time.
But the current issue is right now streaming services dwarf theaters today. The Paramount decree was officially suspended by this administration and its courts on this matter stating it isn't a monopolistic oversight for studios to own and entirely control their streaming services (despite doing the exact same things with "originals" and "exclusives" that led to the original Paramount decree). This administration and its courts not only said the current streaming situation is fine, but that it also means the original Paramount decree no longer applies and studios may own theater chains again, because theaters now compete with streaming.
Skydance having both Paramount+ and HBO Max gives them a huge amount of leverage in the streaming space that is going to get stranger with this consolidation, and gets back to why that 200+ years of combined film history is important and relevant.
Do you think Deno was real competition for Cloudflare, and now that they've merged we don't have alternative options for goods/services that are mostly essential?
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
Workers against Deno Deploy? And even if you don't count Deno as a whole in the same market as Cloudflare it's still shady as hell. They had plans to buy out a company with the explicit intent to shut down their main product.
You would expect them to integrate Deno with Workers, make a new official managed service that would probably become profitable in no time with Cloudflare's cost optimized infra, or at least commit to basic security fixes until the community finds new maintainers.
What they pulled off instead is the most toxic form of acqui hire ever invented.
> They had plans to buy out a company with the explicit intent to shut down their main product.
I understand why it looks that way, and we knew it would be hard to combat this perception.
But it's simply not true.
The actual story is simply this: The Deno team made a strategic decision to refocus on celld, and we (Cloudflare) are excited to support this work, for the reasons I explained in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/
"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."
It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.
Funny that with Bun being acquired by Anthropic, if this big bet on AI doesn't work out we'll end up right back where we started; Node. Obviously Deno will still be OSS, Bun would likely end up that way too, but you get the idea
It’s immutable npm, you can’t unpublish I believe but yeah it’s trick of allowing one to publish typescript packages rather than compiled js only applies to deno.
The yt-dlp project uses Deno as its default and preferred JavaScript runtime when downloading YouTube videos (this replaced their own handwritten JS interpreter). Fortunately yt-dlp also has support for Node and QuickJS as well as deprecated support for Bun, but I don’t think any of those were preferred by the project for various reasons such as portability, security and I think also speed.
As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad". They might reevaluate that in light of things being generally fine and losing their precious handcoded runtime choice.
If I remember correctly, Deno was always priority number 1 due to having a permissions system. Bun's removal due to the rewrite had people complaining using Deno as the focus as Deno's development shifted towards being LLM heavy. Node now supporting permissions would likely be the priority now.
There was a ton of criticism beyond "ai bad". A complete rewrite, in a different language, is a brand new project. It doesn't have any where near the hardening as the previous version thousands of deployments. If they had done that exact same thing but without AI people still would have been upset.
> As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad".
Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.
I don't think that's a good interpretation of what happened.
Bun's release cadence dropped because they had just ported to a new language and they weren't about to release that to their community without letting it settle in for a couple of months first - which they did, by running it in Claude Code on millions of computers.
For context, the Rust rewrite started May 4th, landed on main May 14th, the last remaining Zig code was deleted June 24th, and the first stable Rust release was cut on August 19th. Prior to that people had to test the daily unstable releases.
I think it takes quite severe motivated reasoning to look at a project that ported from one language to another and shipped to millions of end users without incident (Claude Code users didn't even realize they were running the new version) and conclude it was a "fiasco".
The fiasco was that a lot of people were unhappy about it. I'd be interested in seeing a Venn diagram of people who complained about the Bun rewrite and people who don't like AI-assisted programming. I suspect the overlap is heavy.
> Development stalled? Here are the stats on commits to Bun in the past six months
You know you're putting up bullshit metrics, not much different than counting lines of code touched by commits.
If you were forthcoming and showed relevant metrics such as release cadence (i.e., what projects declare to be relevant units of work to be delivered to their userbase) you'd be faced with the realization that since march (bun v1.13.14) Bun only managed to put together 4 meager releases:
* Bun v1.14.0 - Aug 20 (first release in 5 whopping months?)
* Bun v1.14.1 - Sep 4
* Bun v1.14.2 - Sep 5 (emergency regression fix)
* Bun v1.14.3 - Oct 10 (just a few hours ago)
This means in the last half year, following the rewrite the project barely managed to put together 3 patch releases. In semver terms this means no feature work, mind you.
Considering one of those releases was a full rewrite to a new language yes, I do consider that productive.
There were a ton of new features in 1.14.0 - most of the release notes were about new features, the Rust thing was a side note: https://bun.com/blog/bun-v1.4
> It adds Bun.Image, Bun.WebView, Bun.markdown, Bun.cron(), Bun.Terminal, bun run --parallel, bun test --parallel, bun audit fix, bun dedupe, and bun prune. And it rewrites Bun from Zig to Rust.
> Considering one of those releases was a full rewrite (...)
I'm not sure you're you're being serious. It feels you're desperately trying to be disingenuous to avoid addressing the elephant in the room.
Listen: this discussion is on how Bun's release cycle stalled due to the rewrite and after the rewrite.
I repeat: Bun 1.4 was released way back in August. Since the rewrite the project barely managed to release two patch releases,and one of them is a hotfix mere hours after the first patch release. Being able to put together at best two patch releases in two months, specially after a major rewrite that is renowned for failing to follow idiomatic Rust practices and in spite of a bottomless AI budget and a militant attitude towards AI, is a colossal red flag. There is no way around it.
What makes Deno more suitable for this than any other runtime? It's just executing JS code right? I wouldn't think this would leave any meaningful fingerprint.
yt-dlp executes code from the website to get the exact download URLs and header values. The websites obfuscate these to prevent downloading. Running arbitrary 3rd party code in Node or Bun might work, but is risky, especially when that code could potentially come from one of the many ads on that video website.
The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.
I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.
I'd say it's durable object specific. Both team deno and cloudflare (and many others) have been won over by the paradigm. Cloudflare is just the primary implementers of it as a strong example of an actor-based programming model at infra layer, but others have been trying to push it (Rivet, and TerseAI's durable actors, celld)
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
‘Acquires’ is an interesting word, given they’re hiring people and sunsetting the product. They didn’t buy Deno, they hired the team that built it and that forces them to abandon the project.
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land.
I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.
Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.
If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)
> since it push on semantics that can only be run on Cloudflare infrastructure
No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).
Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.
> workerd and its semantics are not exclusive to Cloudflare infrastructure
I believe they are. You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).
All those are primitives that already exist in the non CF world: KV can be easily redis/memcached. Queues, Kafka and so on. I believe that a system that reuses those would be stronger.
> I really wish I was allowed to say who because one of the users is hilariously ironic
Ok, this peaked my curiosity. Would be great if you could share it!
> You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).
Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure.
In fact, celld has already done a lot of this.
> Ok, this peaked my curiosity. Would be great if you could share it!
You'll have to find me in person over drinks somehow. ;)
This is just normal open source. The software is provided AS IS, WITHOUT ANY WARRANTY.
As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?
I'm very surprised they are not running with the runtime. That seemed like Deno's secret sauce? The rest of it is very aligned with Cloudflare already, deploy, kv, workers, etc seems like the lower hanging fruit.
It's almost certainly not worth it. Having less software that you can keep more reliable is almost always worth it over having more software just because it's 10% faster or whatever. This isn't always true but it's mostly true.
So what am I supposed to do, just congratulate them and avoid any critical thought so as not to get downvoted into negative territory on my first day commenting on HM after 5 years of staying away for this exact reason?
As a bystander, I'm excited by this. I don't know what it'll be, but I have a sense some interesting, powerful, and secure new ways of shipping code could come from this marriage...
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
I mean, sure, but this doesn't preclude CF from keeping a few people around who can work on the runtime while everyone else does... whatever CF wants them to do.
They don't even need to be the long term stewards either. Spend some time setting up a proper governance structure for Deno, hand it off, and then pay some maintainers to continue their existing effort.
At least how it's stated in the post, it really feels like an "ah good luck everyone, I'm out!" sorta deal, which seriously sucks for everyone who really believed in Deno.
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
I do appreciate that it's not explicitly anti-competitive, but as a biochemist who spent a lot of time thinking about living systems, I am a bit concerned about a budding ecology that has perhaps collapsed <3
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
> once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.
I suspect he's come to the conclusion that the runtimes are now just a commodified build system that's been dialed in already, and the layer where celld sits is where the next unvalidated opportunities are
It's a joint decision and I agree with it. I'm most invested in its success and have put the most work into it - and I no longer think it's where I can do the most important work. There are some good ideas in Deno and it's well engineered - but it ultimately is not solving big problems. It has been sucked into the gravity well of node compatibility, which forces it to behave exactly as Node does. Why reimplement Node? It works. Marginal performance or UX or security benefits are not enough.
I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032
We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
Why let it get sucked into the gravity well of node compatibility then? How can the community carry it forward without you? Will CloudFlare release the name/assets, or it will have to be forked?
FWIW I think the project is likely highly maintainable with relatively small economic commitment. I would be willing to contribute. If anyone wants to discuss how we keep it going past the next year, please let me know.
Thanks for your response, ry. It's hard to put into words how much I appreciate your work, both on Node and Deno. Honestly, you saved me from a career as a Java dev. :) I've been using Node since 2013 and Deno since 2018 (when it was still written in Go)... I used both first for hobby projects and scripting and later, when they matured, also at work.
I disagree that there's little differentiation between Node and Deno these days. Sure, I love Deno's UX and tooling, but the security benefits Deno has over Node are still the number one reason, we're picking Deno over Node at work. I'm honestly sad we may have to reconsider and switch.
I understand you are working on a new model for server development and I'll take a look at celld for sure. But what about scripts? I have a couple hundred repositories all using Deno for a wide range of scripting tasks. I'd love to continue using Deno for scripting for another 8 years or longer.
I'm just feeling a bit sad, you know. It kinda feels like I'm gonna lose a friend. That happy little dinosaur, now standing in the pouring rain again...
To be fair, Deno and Bun's enhancements seemed to do a lot to set a fire under Node and have it implement various things it didn't have when both projects launched. This is a good thing.
I don't often post on the orange website. But this news was enough to make me want to say congratulations, friend.
Looking back now after almost 20 years (Nov 2009 to now for me), I can see the arc from what node was then to what celld can be now as your thinking has evolved
A distributed operating system running in userspace is the primitive that can break apart the siloing that has become the default across the walled gardens we all operate in
So both major (and the only meaningful) possible Node alternatives have been absorbed into proprietary monoliths in the last year. We all know how well the Joyent years went, RIP to open source innovation at this point.
I feel it leaves a bitter flavor how Ryan Dahl pushed so hard for Deno and Deno Deploy for years, just to let them die within 1 year and 6 months respectively.
Thankfully I don't have any codebases that heavily use Deno features, otherwise this would be a steep curve now.
What's with the downvotes? Do people doubt that this type of work is something AI is particularly good at? Or is it just resentment against the resulting fact that making the right architectural decisions isn't as important as it was?
That's a pretty uncharitable take. It literally only exists because of him, he pushed hard for it for years, and now he's decided not to anymore it leaves a bitter taste? What do you want him to do?
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
Congrats. But also terrible news for the ecosystem; this project was a bit doomed from the start, and they acknowledge it multiple times (implicitly), but nice to have competition, I guess.
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
No if that were true they wouldn't be stopping development of Deno, which as it stands sits in the best position for codemode given it's granular sandboxing.
I agree it would be an awkward choice for an agent that runs as a local application, but the trend I think is towards agents running more and more on servers.
446 comments
[ 0.20 ms ] story [ 61.6 ms ] threadof course i’m only talking about deno, the technology not deno, the cloud service.
vs
Download, prompt, test, prompt, wait because of 5 hour limit, prompt, test, run
Again, thanks to the MIT license.
Bad news, sorry, the article says:
> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
Sounds like Celld will live on within workerd, Deno is over.
From TFA: We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.
So unless someone else picks up development, Deno will no longer be supported.
Deno built celld, which implements the Workers and Durable Objects programming model with self-hosting in mind. Cloudflare says its own distributed infrastructure is too complicated for straightforward self-hosting, and it hadn’t successfully solved that problem. For customers who might be reluctant to commit to being locked in to Cloudflare’s infrastructure, having a rock solid self-hosted alternative reduces that reluctance.
What we will probably see in the next few months is a major version of `workerd` which is a rebranded celld with better Cloudflare support. And then a bunch of improvements in further versions. While I think `celld` is a nicer name it makes sense to keep the official Cloudflare product/solution as `workerd`.
I hope the developer experience gets closer to Deno, I'm no fan of setting up all the required Node tooling for proper TypeScript support. I really like Deno. RIP
workerd is really far from production-ready Workers replacement, and seems to be very specifically scoped in such a way that essential parts of why Cloudflare dares to run it are not included in the bundle.
My best guess is you're talking about sandboxing, specifically how we defend ourselves against malicious tenants. Indeed, a lot of how we defend against that is not in workerd, and fundamentally can't be, because it's more than just some code, it's a process requiring active management.
However, you only need that if you have untrusted tenants.
If you are using workerd to self-host your own applications on non-Cloudflare infrastructure, then this isn't a concern for you. You don't have untrusted tenants.
If you are hosting untrusted tenants, then you can put workerd in a micro VM, the same as you'd do with any other popular runtime.
My best guess is that you are suggesting that we should open source our multi-tenant hosting technology, along with workerd.
But this doesn't make sense. No popular JavaScript runtime includes multi-tenant hosting technology. Multi-tenant hosting is the responsibility of the hosting provider. workerd is compatible with other providers' multi-tenant hosting approaches. You do not need our specific technology in order to run Workers apps on other hosting providers, and in fact would not even be particularly useful for that purpose.
(But I admittedly have not actually asked Ryan if he had long-term plans to add a multi-tenant scheduler so maybe I'm wrong.)
I don't really know anything about that area, but didn't Facebook get in some trouble for purchasing Instagram in part due to them being competition.
Surely buying a company out only to close their main offering is defined as anti-competitive?
IMHO, it shouldn't be allowed.
But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.
(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)
(There might be something the state of California could do, but I don't know how much they want to get involved.)
Sumner Redstone came from a movie theater family and formed modern Paramount by buying Viacom (which was spun out of CBS due to antitrust), Paramount, and then later CBS itself. He was able to buy Paramount as a cinema owner because the government abandoned the rule that you couldn't own both the studio and the theater in the 80s.
The corporate history of Hollywood is long and complicated. Skydance is obviously a big topic this month, but Paramount was owned by the Redstone family's National Amusements theater for as long as many of the adults on this site have been alive.
But the current issue is right now streaming services dwarf theaters today. The Paramount decree was officially suspended by this administration and its courts on this matter stating it isn't a monopolistic oversight for studios to own and entirely control their streaming services (despite doing the exact same things with "originals" and "exclusives" that led to the original Paramount decree). This administration and its courts not only said the current streaming situation is fine, but that it also means the original Paramount decree no longer applies and studios may own theater chains again, because theaters now compete with streaming.
Skydance having both Paramount+ and HBO Max gives them a huge amount of leverage in the streaming space that is going to get stranger with this consolidation, and gets back to why that 200+ years of combined film history is important and relevant.
I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).
You would expect them to integrate Deno with Workers, make a new official managed service that would probably become profitable in no time with Cloudflare's cost optimized infra, or at least commit to basic security fixes until the community finds new maintainers.
What they pulled off instead is the most toxic form of acqui hire ever invented.
I understand why it looks that way, and we knew it would be hard to combat this perception.
But it's simply not true.
The actual story is simply this: The Deno team made a strategic decision to refocus on celld, and we (Cloudflare) are excited to support this work, for the reasons I explained in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/
See Ryan's own comment here: https://news.ycombinator.com/item?id=50023277
They got scrutiny over it, sure. But trouble? No, I would say that they did not get into trouble.
"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."
It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.
See https://github.com/yt-dlp/yt-dlp/issues/14404, https://github.com/yt-dlp/yt-dlp/issues/15012, and https://github.com/yt-dlp/yt-dlp/wiki/EJS.
Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.
Bun's release cadence dropped because they had just ported to a new language and they weren't about to release that to their community without letting it settle in for a couple of months first - which they did, by running it in Claude Code on millions of computers.
Nonsense. If that was remotely true we would have seen a wealth of maintenance releases immediately following the rewrite, along with feature work.
However, development completely stalled, even though they can throw ungodly amounts of AI compute at the problem.
Don't you notice an incongruence in your remarks?
(If it had stalled for a year then yeah, you'd have a point. I've seen projects stall for a year or more due to a rewrite.)
For context, the Rust rewrite started May 4th, landed on main May 14th, the last remaining Zig code was deleted June 24th, and the first stable Rust release was cut on August 19th. Prior to that people had to test the daily unstable releases.I think it takes quite severe motivated reasoning to look at a project that ported from one language to another and shipped to millions of end users without incident (Claude Code users didn't even realize they were running the new version) and conclude it was a "fiasco".
The fiasco was that a lot of people were unhappy about it. I'd be interested in seeing a Venn diagram of people who complained about the Bun rewrite and people who don't like AI-assisted programming. I suspect the overlap is heavy.
You know you're putting up bullshit metrics, not much different than counting lines of code touched by commits.
If you were forthcoming and showed relevant metrics such as release cadence (i.e., what projects declare to be relevant units of work to be delivered to their userbase) you'd be faced with the realization that since march (bun v1.13.14) Bun only managed to put together 4 meager releases:
* Bun v1.14.0 - Aug 20 (first release in 5 whopping months?)
* Bun v1.14.1 - Sep 4
* Bun v1.14.2 - Sep 5 (emergency regression fix)
* Bun v1.14.3 - Oct 10 (just a few hours ago)
This means in the last half year, following the rewrite the project barely managed to put together 3 patch releases. In semver terms this means no feature work, mind you.
Is this what you call productive.
https://github.com/oven-sh/bun/releases
There were a ton of new features in 1.14.0 - most of the release notes were about new features, the Rust thing was a side note: https://bun.com/blog/bun-v1.4
> It adds Bun.Image, Bun.WebView, Bun.markdown, Bun.cron(), Bun.Terminal, bun run --parallel, bun test --parallel, bun audit fix, bun dedupe, and bun prune. And it rewrites Bun from Zig to Rust.
I'm not sure you're you're being serious. It feels you're desperately trying to be disingenuous to avoid addressing the elephant in the room.
Listen: this discussion is on how Bun's release cycle stalled due to the rewrite and after the rewrite.
I repeat: Bun 1.4 was released way back in August. Since the rewrite the project barely managed to release two patch releases,and one of them is a hotfix mere hours after the first patch release. Being able to put together at best two patch releases in two months, specially after a major rewrite that is renowned for failing to follow idiomatic Rust practices and in spite of a bottomless AI budget and a militant attitude towards AI, is a colossal red flag. There is no way around it.
Everything else is completely negligible.
yt-dlp executes code from the website to get the exact download URLs and header values. The websites obfuscate these to prevent downloading. Running arbitrary 3rd party code in Node or Bun might work, but is risky, especially when that code could potentially come from one of the many ads on that video website.
See https://github.com/denoland/deno/discussions/9811
The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.
I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.
RIP Deno
EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing
Language really means nothing these days…
(Yeah I’m salty, I got all in on Deno a year ago.)
Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.
If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)
[1] https://x.com/KentonVarda/status/2108559594691690663
[2] https://edgejs.org/
No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).
Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.
This was emphasized in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/
> workerd and its semantics are not exclusive to Cloudflare infrastructure
I believe they are. You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).
All those are primitives that already exist in the non CF world: KV can be easily redis/memcached. Queues, Kafka and so on. I believe that a system that reuses those would be stronger.
> I really wish I was allowed to say who because one of the users is hilariously ironic
Ok, this peaked my curiosity. Would be great if you could share it!
Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure.
In fact, celld has already done a lot of this.
> Ok, this peaked my curiosity. Would be great if you could share it!
You'll have to find me in person over drinks somehow. ;)
That's great to hear.
> You'll have to find me in person over drinks somehow. ;)
Challenge accepted!
As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?
https://github.com/ubernaut/exotui
https://ubernaut.github.io/exotui/
Isn't that what FLOSS is all about?
edit: my reaction was too soon, it seems like they will be explicitly working on making workerd an open source self hostable runtime
So Deno is going to be unsupported and will no longer be maintained and will be discontinued.
It looks like "written in Rust" is not enough for a selling point and lost out to the fierce competition against Bun.
Finally, the next step of forking Node is up for grabs:
Node > Deno > Done (anyone?)
Extremely disappointing...
CF has its own quirky serverless technology and has no interest in funding any competition, even/especially in such sad shape as Deno is
They don't even need to be the long term stewards either. Spend some time setting up a proper governance structure for Deno, hand it off, and then pay some maintainers to continue their existing effort.
At least how it's stated in the post, it really feels like an "ah good luck everyone, I'm out!" sorta deal, which seriously sucks for everyone who really believed in Deno.
CF workerd is only one out of those 5.
https://blog.cloudflare.com/deno-joins-cloudflare/
TL;DR: Ryan and co. will be merging celld with workerd to create one first-class open source self-hostable runtime for Workers and Durable Objects. In the post I explain in the post why, contrary to what you might think, this is good business for Cloudflare and we're very excited about it.
But I do have a strangely high trust in the individuals involved (you, Ryan, Sunil, others), even though I am a bit perplexed by CloudFlare's incentives or economics
Which is to say: I am choosing to be optimistic :)
Caveat, am commenting before reading, mind you -- just my general reaction to mergers in a world that never cleaves :)
EDIT: though this has also probably deflated a lot of the good-faith conversations I was having with gov-adjacent Europeans about celld being a boon for the moment of heightened European sovereignty, where EU data residency isn't necessarily considered enough distance anymore.
> once you see it, you'll realize there's no point to traditional javascript runtimes in serving applications - only for build processes (eg bundling) and scripting.
I suspect he's come to the conclusion that the runtimes are now just a commodified build system that's been dialed in already, and the layer where celld sits is where the next unvalidated opportunities are
I'm interested in building powerful new abstractions. celld has been working remarkably well, depending only on object storage for coordination and persistence. It is not just a slightly different API to interact with the file system or network - it's an entirely new model for server development. I wrote a bit about it here: https://x.com/rough__sea/status/2105853283617440032
We'll ship monthly releases for a year, and Deno stays MIT-licensed. If people want to carry it forward, I'd like that.
I disagree that there's little differentiation between Node and Deno these days. Sure, I love Deno's UX and tooling, but the security benefits Deno has over Node are still the number one reason, we're picking Deno over Node at work. I'm honestly sad we may have to reconsider and switch.
I understand you are working on a new model for server development and I'll take a look at celld for sure. But what about scripts? I have a couple hundred repositories all using Deno for a wide range of scripting tasks. I'd love to continue using Deno for scripting for another 8 years or longer.
I'm just feeling a bit sad, you know. It kinda feels like I'm gonna lose a friend. That happy little dinosaur, now standing in the pouring rain again...
The DX of Deno far surpasses Node (or at least it did, idk if Node has caught up in that regard).
What are the big problems you see that still need solving that a future Deno (fork) could handle?
Looking back now after almost 20 years (Nov 2009 to now for me), I can see the arc from what node was then to what celld can be now as your thinking has evolved
A distributed operating system running in userspace is the primitive that can break apart the siloing that has become the default across the walled gardens we all operate in
All the best in what's to come
Things don’t always shake out as you plan
> Deno people probably just want a paycheck after they spent years seeking glory and money on something that other people used but didn't pay them a cent for.
My take: Opensource-Infrastructure-as-startup-but-also-charity is a thing that is going to die along with ZIRP. I don't know why VCs ever sniffed around things like this in the first place. The younger generation that followed this business model with liberal "take my stuff" licenses and sneered at GPL etc are learning the hard way that making a nice cool thing and getting noticed is not going to earn you a good living. (And other people will make millions off your passionate work.)
Ultimately I only trust Node.js to succeed. Bun being too deep into "shipping anything that increases usage".
Deno was a nice alternative with easy configuration and I loved KV and running it on a VPS.
https://blog.cloudflare.com/code-mode/
Given it's server focus though, I'd be very surprised if it was as good as Deno for giving agents a local code sandbox.
Also another blog post from when the feature became generally available: https://blog.cloudflare.com/dynamic-workers/
I agree it would be an awkward choice for an agent that runs as a local application, but the trend I think is towards agents running more and more on servers.