4 ms·

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

by kibwen 5mo ago

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

scuff3d 5mo ago
[dead]
parchley 5mo ago
The author kept bragging about classes of bugs that would not happen with Rust.
- Anon1096 5mo ago
  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++.
  - Henchman21 5mo ago
    Its almost like AI is rotting our brains?
  - awesome_dude 5mo ago
    [flagged]
    - pdimitar 5mo ago
      And yet, all I ever see are attacks against these convenient bogeymen with artistic exaggerations like yours... but I never see the bogeymen themselves.
      - awesome_dude 5mo ago
        You've never seen the Rust evangelists? I am genuinely jealous. Also, I know you made a typo, but it did make me laugh Bogeymen is what you meant Boogymen reminds me of the joke in Millenium Man (How do you make a handkerchief dance - put a little boogie in it)
        pdimitar 5mo ago
        I actually have not, for real. And I keep getting beaten up here on HN just for daring to say it. Makes you think who is who in this situation. Bullies screaming they are the victims.
        awesome_dude 5mo ago
        A quick scan of your comment history suggests that you see one every day ;) And - the number of times I have been grossly downvoted for daring to utter a true word about Rust (or even Rust adjacent) will let you know your non-existent Rust evangelists are indeed the bullies - with one now screaming that he is a victim. If you want definitive proof - look at this sub thread where you're so triggered that people talk about the mere existence of Rust evangelists (and evangelists exist for every tech - they always have and always will - which you would know given your [claimed] history in the field) that you want to argue they they aren't evangelists, they're just poor misunderstood victims. Note: I say claimed not as a jab but because I don't know you and can only go on your claims in your profile.
        pdimitar 5mo ago
        My comment history? The very same one that keeps trying to extract out the location of those supposed Rust zealots and never even getting a single response except yesterday... and the linked comment was pretty mild? But I always get downvoted for having the gall to ask? That comment history? Surely you mistyped that part of your comment with the one I wrote above, right? Understandable. I guess we'll have to agree that we live in parallel realities though, reading your comment -- which I do find genuinely puzzling. Because I keep not seeing evangelists and the only one using troll-like language here is you, not me ("triggered", really?). I am looking at the sub-thread. I guess I need new glasses. Still not seeing anyone fanatical / zealot or whatever. What I see are people who try to ground a discussion because a top comment happily tears down a straw man, and those comments are attempting to show that. > Note: I say claimed not as a jab Oh, I am sure. Your comment absolutely cannot be mistook for that.
  - defen 5mo ago
    > 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/PathString.rs#L111-L119 https://github.com/oven-sh/bun/blob/main/src/bun_core/string...
    - delamon 5mo ago
      can't help myself: how common to see code like https://github.com/oven-sh/bun/blob/main/src/bun_core/string/PathString.rs#L8 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 5mo ago
    > 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.
veidr 5mo ago
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 5mo ago
  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 5mo ago
    But nobody makes announcements and blog posts about running that.
    - Ar-Curunir 5mo ago
      And indeed, the bun team has not done that
      - Dylan16807 5mo ago
        Did they not make the announcement? And they definitely promised a blog post even if it's not out yet.
        Ar-Curunir 5mo ago
        Not on their blog, website, or twitter, so no?
    - pgporada 5mo ago
      There's several blog posts here. https://www.memorysafety.org/initiative/av1/ https://www.memorysafety.org/initiative/av1/
CamouflagedKiwi 5mo ago
They didn't have to. There's a widely held assumption that Rust == safe, or safer than anything else.
- pornel 5mo ago
  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.
dathinab 5mo ago
> 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).`
lucideer 5mo ago
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).

by kibwen 5mo ago

scuff3d 5mo ago

[dead]

parchley 5mo ago

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

Anon1096 5mo ago
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++.
- Henchman21 5mo ago
  Its almost like AI is rotting our brains?
- awesome_dude 5mo ago
  [flagged]
  - pdimitar 5mo ago
    And yet, all I ever see are attacks against these convenient bogeymen with artistic exaggerations like yours... but I never see the bogeymen themselves.
    - awesome_dude 5mo ago
      You've never seen the Rust evangelists? I am genuinely jealous. Also, I know you made a typo, but it did make me laugh Bogeymen is what you meant Boogymen reminds me of the joke in Millenium Man (How do you make a handkerchief dance - put a little boogie in it)
      - pdimitar 5mo ago
        I actually have not, for real. And I keep getting beaten up here on HN just for daring to say it. Makes you think who is who in this situation. Bullies screaming they are the victims.
        awesome_dude 5mo ago
        A quick scan of your comment history suggests that you see one every day ;) And - the number of times I have been grossly downvoted for daring to utter a true word about Rust (or even Rust adjacent) will let you know your non-existent Rust evangelists are indeed the bullies - with one now screaming that he is a victim. If you want definitive proof - look at this sub thread where you're so triggered that people talk about the mere existence of Rust evangelists (and evangelists exist for every tech - they always have and always will - which you would know given your [claimed] history in the field) that you want to argue they they aren't evangelists, they're just poor misunderstood victims. Note: I say claimed not as a jab but because I don't know you and can only go on your claims in your profile.
        pdimitar 5mo ago
        My comment history? The very same one that keeps trying to extract out the location of those supposed Rust zealots and never even getting a single response except yesterday... and the linked comment was pretty mild? But I always get downvoted for having the gall to ask? That comment history? Surely you mistyped that part of your comment with the one I wrote above, right? Understandable. I guess we'll have to agree that we live in parallel realities though, reading your comment -- which I do find genuinely puzzling. Because I keep not seeing evangelists and the only one using troll-like language here is you, not me ("triggered", really?). I am looking at the sub-thread. I guess I need new glasses. Still not seeing anyone fanatical / zealot or whatever. What I see are people who try to ground a discussion because a top comment happily tears down a straw man, and those comments are attempting to show that. > Note: I say claimed not as a jab Oh, I am sure. Your comment absolutely cannot be mistook for that.
- defen 5mo ago
  > 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/PathString.rs#L111-L119 https://github.com/oven-sh/bun/blob/main/src/bun_core/string...
  - delamon 5mo ago
    can't help myself: how common to see code like https://github.com/oven-sh/bun/blob/main/src/bun_core/string/PathString.rs#L8 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 5mo ago
  > 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.

veidr 5mo ago

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 5mo ago
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 5mo ago
  But nobody makes announcements and blog posts about running that.
  - Ar-Curunir 5mo ago
    And indeed, the bun team has not done that
    - Dylan16807 5mo ago
      Did they not make the announcement? And they definitely promised a blog post even if it's not out yet.
      - Ar-Curunir 5mo ago
        Not on their blog, website, or twitter, so no?
  - pgporada 5mo ago
    There's several blog posts here. https://www.memorysafety.org/initiative/av1/ https://www.memorysafety.org/initiative/av1/

CamouflagedKiwi 5mo ago

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

pornel 5mo ago
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.

dathinab 5mo ago

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

lucideer 5mo ago

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