5 ms·

Do you think Bun's migration was irresponsible?

ricardobeat 2mo ago
Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear. Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.
- docmars 2mo ago
  Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place. It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way. Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
  - Tadpole9181 2mo ago
    Not sure I understand. Bun's changes are merged on the dev branch and available for use, no? EDIT: Oh, look, blog post on the front page now. https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust > Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now. So, yes, it seems it was definitely more than a "marketing stunt" and it's broadly available and slated to be the production release soon.
    - NamlchakKhandro 2mo ago
      [flagged]
    - jibal 2mo ago
      [flagged]
    - pjmlp 2mo ago
      The irony is that the blog post actually points out as pain points the reasons many of us assert languages like Zig are out of place in the 21st century. A nice collection of heap-use-after-free crash, use-after-free crash, crash and out-of-bounds read, memory leak, double-free crash, race condition crash.
    - moogly 2mo ago
      A minor version bump? Exciting times we live in.
      - Tadpole9181 2mo ago
        What exactly is your complaint? It doesn't make any breaking changes. That's how semantic versioning works.
    - andai 2mo ago
      Bun is infrastructure. Why would I want my infrastructure to be unstable? (By the way, 10,000 unsafe blocks last I checked, though the number is going down somewhat.)
      - Tadpole9181 2mo ago
        I've never used bun on production for this very reason. But nevertheless, tens of thousands of people and businesses do. And I'm not sure how you're responding to my comment. The parent said "this is a marketing stunt" derogatorily, as if it's slop that doesn't work. This is already the canary build, it's more stable than the current stable, and is actively in production products in wide use. The parent is objectively wrong, whether or not I personally use Bun.
  - golergka 2mo ago
    Marketing could of course be one of the main motivations, but it's not a "stunt". More like a marketing achievement, I guess? Stunt implies smoke and mirrors, and bun rewrite is quite real.
  - jorisw 2mo ago
    Also it cost $165K in tokens
    - Cthulhu_ 2mo ago
      Probably cheaper than doing it by hand, however, that's the short term "port x to y" cost, the longer term cost (or benefit) is a lot harder to calculate.
- spartanatreyu 2mo ago
  > this TS migration started long before AI was able to help Yes, but that doesn't mean it wasn't also "helped" along by AI. See: 1. https://github.com/microsoft/typescript-go/pull/1387 https://github.com/microsoft/typescript-go/pull/1387 2. https://github.com/microsoft/typescript-go/pull/2978 https://github.com/microsoft/typescript-go/pull/2978 3. https://github.com/microsoft/typescript-go/pull/1138 https://github.com/microsoft/typescript-go/pull/1138 4. etc... Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git. --- The initial port was automated, then devs got in there, then LLMs got in there.
bastawhiz 2mo ago
It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.
- jitl 2mo ago
  yeah but, the existing code was also full of bugs, so isn’t it all a wash in the end?
  - bastawhiz 2mo ago
    The initial state has no bearing on whether the process was responsible or not. That's measuring along a different axis. If the bun rewrite lands and it breaks someone's app, that's bad no matter whether there's more or fewer bugs in the final state. The important metric in a rewrite of software that's used in production is stability.
    - vlovich123 2mo ago
      inevitable: https://xkcd.com/1172/ https://xkcd.com/1172/
      - bastawhiz 2mo ago
        It's really not even close to being the same. In the best case, a bug means your app crashes on the new version. In the worst case, something more insidious happens like opening a security vulnerability (say, TLS isn't handled correctly or HTTP headers are mishandled in a way that allows SSRF or request smuggling) or a previously linear time operation is accidentally quadratic (leading to DoS).
        vlovich123 2mo ago
        You can apply the same FUD to the old version. Your argument basically is “all change brings risk” which is true but doesn’t add any useful insight. It’s always easy to complain and warn about change causing problems while ignoring the problems of the status quo. The “everything is fine” meme in action.
mindwok 2mo ago
I don't think irresponsible is the right word, but it has drastically reduced Bun's appeal. All the tools we use have a brand to them, and Bun basically changed their brand overnight to "reckless" in my eyes.
- jitl 2mo ago
  bun has never been fit for production, at least not for load bearing business apps. it’s been haunted by segfault bug reports since the early days, and i personally hit at least one a week when im doing lots of bun stuff. im excited for bun with less segfaults
  - brandensilva 2mo ago
    So reckless but needed.
replygirl 2mo ago
it's impossible to say, as v1.4 is in development and there has been no migration
phplovesong 2mo ago
Its was basically "hey claude, rewrite this"
sdevonoes 2mo ago
I would say it was a joke. Cannot take it seriously

Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear. Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.

docmars 2mo ago
Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place. It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way. Too many see it as this miraculous one-shot and are using it as a blueprint to justify more layoffs and buzzword salad in their boisterous LinkedIn announcements about how they're "completely overhauling their strategy" in engineering. Hogwash.
- Tadpole9181 2mo ago
  Not sure I understand. Bun's changes are merged on the dev branch and available for use, no? EDIT: Oh, look, blog post on the front page now. https://bun.com/blog/bun-in-rust https://bun.com/blog/bun-in-rust > Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now. So, yes, it seems it was definitely more than a "marketing stunt" and it's broadly available and slated to be the production release soon.
  - NamlchakKhandro 2mo ago
    [flagged]
  - jibal 2mo ago
    [flagged]
  - pjmlp 2mo ago
    The irony is that the blog post actually points out as pain points the reasons many of us assert languages like Zig are out of place in the 21st century. A nice collection of heap-use-after-free crash, use-after-free crash, crash and out-of-bounds read, memory leak, double-free crash, race condition crash.
  - moogly 2mo ago
    A minor version bump? Exciting times we live in.
    - Tadpole9181 2mo ago
      What exactly is your complaint? It doesn't make any breaking changes. That's how semantic versioning works.
  - andai 2mo ago
    Bun is infrastructure. Why would I want my infrastructure to be unstable? (By the way, 10,000 unsafe blocks last I checked, though the number is going down somewhat.)
    - Tadpole9181 2mo ago
      I've never used bun on production for this very reason. But nevertheless, tens of thousands of people and businesses do. And I'm not sure how you're responding to my comment. The parent said "this is a marketing stunt" derogatorily, as if it's slop that doesn't work. This is already the canary build, it's more stable than the current stable, and is actively in production products in wide use. The parent is objectively wrong, whether or not I personally use Bun.
- golergka 2mo ago
  Marketing could of course be one of the main motivations, but it's not a "stunt". More like a marketing achievement, I guess? Stunt implies smoke and mirrors, and bun rewrite is quite real.
- jorisw 2mo ago
  Also it cost $165K in tokens
  - Cthulhu_ 2mo ago
    Probably cheaper than doing it by hand, however, that's the short term "port x to y" cost, the longer term cost (or benefit) is a lot harder to calculate.
spartanatreyu 2mo ago
> this TS migration started long before AI was able to help Yes, but that doesn't mean it wasn't also "helped" along by AI. See: 1. https://github.com/microsoft/typescript-go/pull/1387 https://github.com/microsoft/typescript-go/pull/1387 2. https://github.com/microsoft/typescript-go/pull/2978 https://github.com/microsoft/typescript-go/pull/2978 3. https://github.com/microsoft/typescript-go/pull/1138 https://github.com/microsoft/typescript-go/pull/1138 4. etc... Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git. --- The initial port was automated, then devs got in there, then LLMs got in there.

bastawhiz 2mo ago

It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.

jitl 2mo ago
yeah but, the existing code was also full of bugs, so isn’t it all a wash in the end?
- bastawhiz 2mo ago
  The initial state has no bearing on whether the process was responsible or not. That's measuring along a different axis. If the bun rewrite lands and it breaks someone's app, that's bad no matter whether there's more or fewer bugs in the final state. The important metric in a rewrite of software that's used in production is stability.
  - vlovich123 2mo ago
    inevitable: https://xkcd.com/1172/ https://xkcd.com/1172/
    - bastawhiz 2mo ago
      It's really not even close to being the same. In the best case, a bug means your app crashes on the new version. In the worst case, something more insidious happens like opening a security vulnerability (say, TLS isn't handled correctly or HTTP headers are mishandled in a way that allows SSRF or request smuggling) or a previously linear time operation is accidentally quadratic (leading to DoS).
      - vlovich123 2mo ago
        You can apply the same FUD to the old version. Your argument basically is “all change brings risk” which is true but doesn’t add any useful insight. It’s always easy to complain and warn about change causing problems while ignoring the problems of the status quo. The “everything is fine” meme in action.

mindwok 2mo ago

I don't think irresponsible is the right word, but it has drastically reduced Bun's appeal. All the tools we use have a brand to them, and Bun basically changed their brand overnight to "reckless" in my eyes.

jitl 2mo ago
bun has never been fit for production, at least not for load bearing business apps. it’s been haunted by segfault bug reports since the early days, and i personally hit at least one a week when im doing lots of bun stuff. im excited for bun with less segfaults
- brandensilva 2mo ago
  So reckless but needed.

replygirl 2mo ago

it's impossible to say, as v1.4 is in development and there has been no migration

phplovesong 2mo ago

Its was basically "hey claude, rewrite this"

sdevonoes 2mo ago

I would say it was a joke. Cannot take it seriously