[bastawhiz]

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]

inevitable: https://xkcd.com/1172/

[bastawhiz]

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]

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.

[bastawhiz]

Sure, all change brings risk. But this is change where:

1. The change isn't made by a human.

2. The change wasn't fully reviewed by humans or machines. It's not currently possible for a machine to review the whole thing as one.

3. It's a full rewrite. This isn't a ten thousand line change, it's multiple orders of magnitude more than that.

You're literally making the argument that all risk of any size from any change of any size is equivalent, so just don't worry about it. If you relied on this software before, good luck convincing yourself it's fine to rely on this software now: it's literally not the same software anymore.

[vlovich123]

No I’m not making that argument, you’re the one making that claim as if it’s the only alternative to your position.

My position is more nuanced. A) what does the test coverage look like B) how is the deployment managed.

I suspect B is going to be my biggest issue - normally you’d deploy this slowly over time to monitor problems and whatnot. But ultimately the real test is seeing how it actually performs in the wild and kinds of problems people report. But you can always keep using the zig version if you wanted. So ultimately it’s a lot of consternation over a nothing burger. You can laugh at them if they screw up the release, but it’s a bold attempt at trying something legit. It took Microsoft 2 years of many engineer hours migrating typescript to Go. If it takes significantly less calendar time and human time, you could reasonably even evaluate what a Rust based typescript looks like vs Go if you wanted to for an order of magnitude cheaper.