[dangerlibrary]

There's a book that changed a lot of the way I think about attention and media [0]. The book isn't very good, but it flags something relevant here. There is a huge asymmetry between the reach of 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).

This asymmetry is well understood by marketing and PR professionals, and actively exploited.

[0] https://en.wikipedia.org/wiki/Trust_Me,_I%27m_Lying

[rcxdude]

Hmmm, given the general mood in this case, I feel like there's a lot of people keen to find any criticism of the code they can and amplify it as possible. Most of it strikes me as relatively shallow at the moment, though (that is, apart from the fact that merging such a large LLM assisted port is certainly a, uh _bold_ move (to put it lightly), there's not much that people are pointing out about the actual result that feels like it's worse than any other port in progress, but there is definitely a lot of hay being made about any issue that is found).

[antonvs]

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

[rajup]

Idk the pr author did merge it into main and talked about writing a blog post. To me that sounds like the author felt it was ready for public critique and feedback, especially for software with a fair bit of users

[antonvs]

It's not replacing the stable build, and not being claimed as bug-free. "Public critique and feedback" is not meaningful or useful if it just consists of regurgitating what's happening in a more negative and uninformed way.

[stickfigure]

It may just be different expectations about what the `main` branch means. In my organization we don't merge half-finished work into `main`.

[antonvs]

This isn't replacing the Zig stable build at the moment - it would make no sense if it was. It's not unusual to merge separate non-prod functionality to main once something is ready for others to work on.

And realistically, essentially 100% of the people criticizing this don't have the the credentials to do so meaningfully.

[kibwen]

> a big, flashy announcement (here: bun was re-written in memory-safe rust in a couple weeks)

Did they even claim it was "memory-safe"? Every discussion of this topic has had dozens of comments noting that their vibed codebase is bursting at the seams with unaudited unsafe blocks, lightly reviewed by people who seem to not only seem to not understand Rust, but who seem incensed at the idea of needing to understand any programming language in the first place.

[veidr]

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.

[swiftcoder]

Yeah, exactly. The typical approach is to do a mechanical translation such as with rust2c, that is full of unsafe, and then gradually refactor safety in.

[Dylan16807]

But nobody makes announcements and blog posts about running that.

[pgporada]

There's several blog posts here. https://www.memorysafety.org/initiative/av1/

[Dylan16807]

And the first post is about the team working on the project, with about two and a half sentences on c2rust, and making it very clear they just started.

The newer posts go into detail about the rearchitecting that follows.

[Ar-Curunir]

And indeed, the bun team has not done that

[Dylan16807]

Did they not make the announcement? And they definitely promised a blog post even if it's not out yet.

[dathinab]

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

[parchley]

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

[Anon1096]

A bug-for-bug port to Rust is the first step to fixing that. Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code. The difference is now it's known where effort can be dedicated in order to one day have a memory-safe release of Bun. People have absolutely lost their mind over this and completely forgotten the benefits Rust gives you. I feel like I've gone back 10 years reading threads about the Rust port of Bun these are the exact same arguments we see from people advocating continued use of C++.

[defen]

> Assuming the port is actually 1:1 without any behavioral changes, these bugs already exist in the Zig code

The "1:1" assumption is a massive unjustified assumption. Rust and Zig have different memory models, so it's possible to do a "1:1" translation of Zig code to Rust and end up with undefined behavior in Rust.

For example, Zig code might make assumptions about lifetimes based on implicit knowledge of which allocator was used for some memory. That could cause problems in Rust if you erase the lifetime https://github.com/oven-sh/bun/blob/main/src/bun_core/string...

[delamon]

can't help myself: how common to see code like https://github.com/oven-sh/bun/blob/main/src/bun_core/string... instead of simple ilog2()? I guess, ut somewhat explains how they got 700k+ lines of code

[DSMan195276]

> Assuming the port is actually 1:1 without any behavioral changes

It's not, that's clear from this kind of bug popping up. Functionally this bug exists because `PathString` was converted into a "safe" Rust API but still works the same internally as the original Zig code did (via using `unsafe`), that introduces UB that wasn't there in the Zig code.

If it was attempting to be a 1:1 with no behavior changes (like c2Rust attempts to do) then this would not have been turned into a "safe" Rust API like this.

[Henchman21]

Its almost like AI is rotting our brains?

[lucideer]

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

[CamouflagedKiwi]

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

[pornel]

What exactly people mean by "safe(r)" makes all the difference.

It's simply not possible to include all the nuance of safety of a language and all software written in it a single word. This leads to all kinds of miscommunication and strawmanning.

Rust's official line is specific memory safety guarantees, with caveats that it must not be broken by unsafe code, the OS, compiler bugs may happen, etc. Rust also has a bunch of best-effort features that steer users towards more robust code, but can't guarantee it.

This gets twisted in both directions:

- people ignore the caveats and limitations, pretending that Rust promised zero bugs ever, and use any bug in any Rust program as a proof by contradiction that Rust's claims are false.

- or focus solely on the caveats, ignoring all the advancements and incremental improvements, and take a "then why even bother?" There are classes of bugs Rust can't stop. Nothing is foolproof for a sufficiently advanced fool, and an infallible programmer could write bug-free code in any language, which creates a false equivalence between languages.

[pavel_lishin]

Is this the concept that's referred to in the quote "a lie can travel halfway around the world before the truth puts on its shoes"?

[kakugawa]

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

[giancarlostoro]

Not just marketing and PR, the mainstream media knows that pushing out BS and then retracting it later can have lasting effects because people will remember the original article / headline, and never see the correction.

[beberlei]

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.

[giancarlostoro]

Ctrl + F "only" is only in your messaging not mine. I never said they were the only ones doing this? It's not just politicians, celebrities know about this and will use it to their advantage. Whoever makes the headlines first might have a stronger sway over their adversaries. I'm not even poking at any side in particular, this is reality across the board unfortunately. People will just blindly take and believe the primary headlines.

[alpinisme]

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.

[Aurornis]

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?

[tonfa]

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

[jdiff]

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

[whimsicalism]

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

[poncho_romero]

Bun being a high profile project, that has had visible conflicts with Zig over AI contributions, and was recently purchased by Anthropic, is naturally going to make something like this big and flashy regardless of the author's intentions.

[whimsicalism]

So Jarred unintentionally “exploited” a marketing strategy by not making a big flashy announcement (?)

c’mon.

[QuadrupleA]

The effort required to refute bullshit is an order of magnitude more than to create it.