> Most of it strikes me as relatively shallow at the moment

It is. We’re what, a week into this exercise? Absolutely everyone criticizing it, with no exceptions, is behaving like a micromanaging middle manager who couldn’t even dream of doing the work themselves.

I half want to start a list of “people to ignore”, but such people tend to expose themselves in every other comment anyway.

[flagged]

No, and there's been a lot of confusion about that on this website.

They did cite Rust's safety as a motivating factor for the port. That doesn't imply trying to achieve that simultaneously with the language change — which is good, because that would be insane. (Or, if you prefer, even more insane.)

You cannot faithfully port a codebase to a new language while also radically re-architecting it. You have to choose.

They want the safety benefits of Rust going forward; i.e., after it's finished, when they then write new code in Rust.

> Did they even claim it was "memory-safe"?

they didn't,

actually the port is trying to be mostly 1:1 and in turn is mostly unsafe rust, which means no benefits initially

but also doing the 1:1 port to mostly unsafe rust is also only the first step of a full port, you then incrementally go through it fixing issues and remove "unsafe" usage. (And long term likely also doing some refactoring to using more idiomatic rust, but that has less priority).

The problem is there was no blog port describing the whole thing to someone without contextual knowledge. Instead just linked PRs which is in this case somewhat close to a "as if nearly all people only read the HN headline" case :/

Like a more context giving version of the first HN post would have something on the line of `Show HN: Bun is porting to safe rust (PR link), starting with an AI based automatized port to mostly unsafe rust which once it behaves mostly the same as Bun in the test suite will likely be merged. But must be followed up with incremental PRs to remove unsafeness, and likely also a lot of unsoundness related to the way it's ported (some explanation about why this port will have unsoundness).`

The author kept bragging about classes of bugs that would not happen with Rust.

They didn't need to - much of the popular hype around rust is on the back of uninformed spectators confusing Rust's tools for enabling memory-safety (good, warranting hype) with Rust itself guaranteeing automatic memory safety (fantasy).

They didn't have to. There's a widely held assumption that Rust == safe, or safer than anything else.

[dead]

You could view it as a specific application of the quote.

In your quote, there is no time-dependency between the lie and the truth. Whereas here, it's an attractive lie (easily parsed, great narrative), followed up by truths (that need more than surface-level analysis).

only the mainstream media knows about this? Quite odd to qualify media this way here, when most of all media uses this mechanism. We also forgot politicians who are experts in this field.

I don’t think the media care about having lasting effects. They just want to catch the wave of interest and not wait around and let someone else get the scoop while they fact check or add nuance.

> 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).

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).

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