6 ms·

> How is that better than the Zig codebase you started with? In contrast with the Zig codebase, you now have clear well-scoped unsafe boundaries you can iterat

> How is that better than the Zig codebase you started with? In contrast with the Zig codebase, you now have clear well-scoped unsafe boundaries you can iteratively fix one by one. This was not the case before.

cyber_kinetist 2mo ago
> clear well-scoped unsafe boundaries This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)
- baokaola 2mo ago
  There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.
  - Ygg2 2mo ago
    Good job falling for the Zig propaganda. I say that half-jokingly. EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
    - selfmodruntime 2mo ago
      This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.
      - Ygg2 2mo ago
        Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? And how does Miri help solve this issue?
        selfmodruntime 2mo ago
        > Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? By the engineer's wit of course! > And how does Miri help solve this issue? By detecting undefined behavior caused by violation these rules
        dwattttt 2mo ago
        Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
        Ygg2 2mo ago
        > By the engineer's wit of course! Seeing how the Rust compiler isn't an LLM, it can't really work on wit. From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled? > By detecting undefined behavior Say you are tasked with making Miri; how do you detect violations of these rules?
  - selfmodruntime 2mo ago
    It's true and I write Rust and love it dearly. There is an entire book about working with the unsafe keyword and its aliasing rules: https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://doc.rust-lang.org/nomicon/working-with-unsafe.html
  - hota_mazi 2mo ago
    What do you mean? C is unsafe 100% of the time. Rust is only unsafe in unsafe{} blocks.
    - uecker 2mo ago
      This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.
- lolinder 2mo ago
  No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said: > We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships. What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic. Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.
  - cyber_kinetist 2mo ago
    > We can gradually refactor it Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it. Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.
    - Tadpole9181 2mo ago
      You're not helping your case. So if I use Zig, I need to do all of that perfectly from day one and I don't get any help from static analysis to do it. Or else I've poisoned my whole program in scary ways and will require a total refactor where I still won't have any help and once again can't make a single mistake.
      - metoobruh 2mo ago
        You're not helping your case. > [what you just wrote] So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.
        Tadpole9181 2mo ago
        Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine. Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
- selfmodruntime 2mo ago
  There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.
  - cyber_kinetist 2mo ago
    You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)
petesergeant 2mo ago
I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.
lunar_mycroft 2mo ago
Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.
- selfmodruntime 2mo ago
  This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.
  - lunar_mycroft 2mo ago
    You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
    - Tadpole9181 2mo ago
      Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
      - lunar_mycroft 2mo ago
        > Which is still a step ahead of Zig First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient. > What's your point, that if we can't do everything perfectly in one step we can't do it at all? My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.

cyber_kinetist 2mo ago

> clear well-scoped unsafe boundaries This is not done by blindly porting Zig code 1:1 and calling it a day. You do have to make conscious decisions about code architecture to manage Unsafe code, since you need choose the right invariants for your Safe Rust code to conform inside the module (Note that unsafe pollutes the whole module containing it, not just the code inside the unsafe block!)

baokaola 2mo ago
There's only one language that's more dangerous than C and that is unsafe Rust. I say that only half-jokingly.
- Ygg2 2mo ago
  Good job falling for the Zig propaganda. I say that half-jokingly. EDIT: You can't be serious people. Rust unsafe is safer than C, if for nothing else, for knowing which pointers are aliasable.
  - selfmodruntime 2mo ago
    This isn't propaganda, the Rust compiler's rules when using the unsafe keyword are difficult to uphold, which is why the community wrote Miri.
    - Ygg2 2mo ago
      Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? And how does Miri help solve this issue?
      - selfmodruntime 2mo ago
        > Ok, and how does, in your opinion, compiler rules enforcement work in an unsafe block? By the engineer's wit of course! > And how does Miri help solve this issue? By detecting undefined behavior caused by violation these rules
        dwattttt 2mo ago
        Is there a "Rust compiler's rule" you can point to that's harder than avoiding UB in C or C++ in similar circumstances? They strike me as very similar beasts.
        Ygg2 2mo ago
        > By the engineer's wit of course! Seeing how the Rust compiler isn't an LLM, it can't really work on wit. From the POV of a programmer, how would you implement an unsafe block? What is disabled vs what's enabled? > By detecting undefined behavior Say you are tasked with making Miri; how do you detect violations of these rules?
- selfmodruntime 2mo ago
  It's true and I write Rust and love it dearly. There is an entire book about working with the unsafe keyword and its aliasing rules: https://doc.rust-lang.org/nomicon/working-with-unsafe.html https://doc.rust-lang.org/nomicon/working-with-unsafe.html
- hota_mazi 2mo ago
  What do you mean? C is unsafe 100% of the time. Rust is only unsafe in unsafe{} blocks.
  - uecker 2mo ago
    This is nonsense. There is quite a subset of C which is perfectly safe and an even larger one which can easily be safe with tooling. You could argue that unsafe keyword is easier to spot than the unsafe features of C, so that makes it somewhat easier to screen for issues. But if you screen for memory safety only, this is problematic anyhow.
lolinder 2mo ago
No one involved in the port proposed "blindly porting Zig code 1:1 and calling it a day". From the first blog post the creator said: > We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships. What the rewrite does is make the unsafe code greppable, which is a necessary first step to eliminating it and one that's actually achievable rather than going straight to idiomatic. Every successful refractor takes this form of stepwise changes that leave the behavior intact. It just so happens that in this case the first stepwise change was the implementation language.
- cyber_kinetist 2mo ago
  > We can gradually refactor it Is quite a hell of a statement, when memory management issues are highly nonlocal and need some careful design upfront in order for you to nail it. Unsafe isn't something that you can gradually clean up. Even one single flawed usage of unsafe (an ill-assumed invariant) can poison the whole program in scary ways, and might require a total refactor of your codebase to fix it.
  - Tadpole9181 2mo ago
    You're not helping your case. So if I use Zig, I need to do all of that perfectly from day one and I don't get any help from static analysis to do it. Or else I've poisoned my whole program in scary ways and will require a total refactor where I still won't have any help and once again can't make a single mistake.
    - metoobruh 2mo ago
      You're not helping your case. > [what you just wrote] So they gained nothing from a Rust rewrite, except introducing more bugs into their shit codebase.
      - Tadpole9181 2mo ago
        Except the blog post shows that they fixed a hundred or so known issues, patching several memory leaks and making the project viable for Prisma Compute's adoption - which it wasn't before. It's now running in production in two places just fine. Can you point to an equal number of issue tracker tickets showing novel bugs or regressions in the canary build?
selfmodruntime 2mo ago
There is almost zero reason for a public facing, non-embedded project like Bun to use unsafe anywhere.
- cyber_kinetist 2mo ago
  You do have to inevitably use unsafe because of FFI (Bun uses existing C++ modules like JavascriptCore for most functionality). Optionally also for performance (at least if you want to win Deno on that front)

petesergeant 2mo ago

I would go further and say that anyone who doesn't immediately identify this either isn't thinking clearly about this, or is intentionally ignoring it. I have no horse in this race AT ALL and this is _obviously_ the advantage.

lunar_mycroft 2mo ago

Except that writing safe rust often requires designing the architecture around rust's ownership model, meaning a file by file, line by line translation doesn't necessarily leave you much closer to safe rust than you were at the start.

selfmodruntime 2mo ago
This is untrue. You can do a file by file translation by using clone and copy liberally. After you're done, you can incrementally introduce borrowing.
- lunar_mycroft 2mo ago
  You can also do one by using `unsafe` liberally, especially if you're flexible about actually upholding rust's rules (as the bun team just did). But either way, you're still stuck with a code base that's going to need extensive refactoring if you want to actually take advantage of rust.
  - Tadpole9181 2mo ago
    Which is still a step ahead of Zig, which requires an entire rewrite to have the tiniest shred of RAII or borrow checking. What's your point, that if we can't do everything perfectly in one step we can't do it at all?
    - lunar_mycroft 2mo ago
      > Which is still a step ahead of Zig First off, you seem to be under the impression I'm a rust hater. Noting could be further from the truth. Rust is easily my favorite language at this point, I reach for it for basically everything (except quick scripts). While I do like a lot of zig's philosophy, I think at the end of the day the empirical evidence is overwhelming that manual memory management isn't sufficient. > What's your point, that if we can't do everything perfectly in one step we can't do it at all? My point is exactly what I initially said: you typically aren't much closer to a (mostly) safe rust codebase if you've done a line by line port to (partially unsafe) rust than you were to start with. Getting to safe rust is very likely to require substantial refactors either way. This doesn't mean you shouldn't do it (on it's own), but it does mean that the bun team's strategy/assumptions are more questionable than they appear to realize.