I thought you were going to call out the problem in the other direction: There has not been a "big, flashy announcement" because the port is a work in progress. It's not done or released. The only big flashy announcements I see are these drive-by dunk attempts on the work in progress code combined with attempts to imply that they said it was done or perfect.

The rewrite was a code translation meant to be a starting point.

> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks), and the relatively small reach of a correction (often just a footnote on an old article, here a GH issue).

The Bun team never made a big announcement that the code is now memory safe. They've been clear that this is the starting point.

Anyone expecting it to be perfect immediately and to have solved all of the memory problems in the original Zig code is arguing with an announcement they imagined, not what the Bun team has said.

Did anyone try to map this code back to the original codebase to see if this memory problem exists in the original codebase?

A single million line commit overwriting all of main is pretty flashy and high profile. Anyone who was working in this repo previously can throw whatever the heck they were doing out the window. This isn't in a branch, this commit isn't marked WIP, this is now the committed, active, current state of the bun project. That's quite a statement to make, even if there isn't a blog post somewhere (yet).

> Did anyone try to map this code back to the original codebase to see if this memory problem exists in the original codebase?

FWIW what is being discussed is not memory problems, it's breaking rust invariants (the unsafe code has to follow specific rules, e.g. annotate lifetimes properly).

strongly agreed, all of the flashiness is coming from the detractors. the port itself has been quite lowkey