I'm relatively young and my first exposure to life and work of Vint Cerf was through DTN and Interplanetary Internet. What a life of accomplishment!

To quote a friend:

> Well it's objective _to me_

It states $165k in the article

> In Bun v1.3.14, every build leaks about 3 MB, forever

I'm sorry but that is insane, how was this never fixed before the rewrite?

I've been impacted by a couple of bugs in Bun.SQL and lo and behold these were only fixed for 1.4. Presumably Claude could have fixed those in the Zig version but the Bun team decided to not do that.

Furthermore, there's no mention of an LTS plan for the Zig version. It seems that if a CVE is discovered in the future, Bun users will no have no option than to update to the Rust port.

This is not how you run a project that others depend on and enough for me to not touch Bun ever again.

I'm a little puzzled: Why should you care? The language in which Bun is written isn't part of its API, if you will. You care that you have something that does various javascripty things according to a particular spec of what it's supposed to do. If a bug is fixed in 1.4.x it's fixed, why should it matter, really, if that's in Zig or Rust?

Who in their right mind would immediately migrate their production apps into a complete re-write of a runtime?

It would be naive to think there aren't new bugs or changes in behavior introduced in 1.4.

(Well, the answer is "Anthropic, with claude code", but I'm not in possession of material information related to whether they are or are not in their right minds.)

But yes, of course there will be new bugs. But that's why 1.4.x for x > 0 is interesting. If the branch is being used and people are not reporting _more_ bugs, and the bugs you care about it are being fixed (successfully) on it, and it passes your tests, etc., ... I dunno. This is an application domain where you can do some pretty solid testing of it, comparative fuzzing, etc., so it doesn't strike me as entirely mad to jump over after a few minor releases where you can see the bug trajectory.

> Well, the answer is "Anthropic, with claude code"

Anthropic is not exactly the hallmark of engineering excellence... quite the contrary.

> But yes, of course there will be new bugs

Obviously, which is why more thought should have been put into the transition.

Not everyone will want to yolo their production projects into such a massive rewrite overnight.

Reminds me of this old youtube bug where some of the videos that were uploaded ended up upside down because of a phone orientation during recording:

https://bruteforceswimathon.medium.com/youtube-help-my-video...

I'm also writing a blogpost on orbital datacentres, maybe we should compare notes!

Here's my current draft; I expect perhaps 20-30% of it will need rewriting, not counting anything I've yet to add: https://github.com/BenWheatley/blog/blob/main/2026/06/22-23....

Dotnetrocks did an excellent breakdown https://www.dotnetrocks.com/details/2007

Why do you say that? My first exposure to statins was in https://myticker.com and they seem somewhat important

the vast majority of the anti-statin crowd are just regurgitating talking points they heard from people in their diet tribe - usually keto/carnivore

Keyword dynamic, the parameters are quantized on a case by case basis

I can't fucking stand this AI slop writing. If the author couldn't spend time writing it, I won't spend time reading it

We need to distinguish such bad quality AI writing from good quality writing. There is absolutely no reason why AI writing has to be so bad. When it is good, you won't even know.

It's agreed, not agree.

I see. Thanks for pointing out.

Oh he just won this tiny award named after Alfred Nobel

Cool! I’d advocate for OP to put that in the headline, then.