5 ms·

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to t

I just want to comment that I think it's a good change if we look past the AI involvement. Bun has had an extremely high amount of crashes/memory bugs due to them using Zig, unlike Deno which is Rust. Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better

chris_st 5mo ago
And they're clearly marked as `unsafe`, so easy to find, which gives them a nice list of issues to address.
mi_lk 5mo ago
> Bun has had an extremely high amount of crashes/memory bugs Any stats/source? Not that I think it's false > and the ugly parts look uglier (unsafe) which encourages refactoring. Looks like Bun owes that to itself to some extent, not solely because of the language
- enricozb 5mo ago
  I believe the author is the creator of Bun.
  - brazukadev 5mo ago
    Is he working for Anthropic now?
    - danaw 5mo ago
      anthropic bought bun recently
      - brazukadev 5mo ago
        That's exactly my point. The fact they created Bun does not mean they will do what's better for Bun and the people using it.
- Ygg2 5mo ago
  If you look at percent of segfault errors in each repo, Bun had a much larger percent. Although don't quote on me.
- afavour 5mo ago
  FTA: > why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. Not a hard number obviously but a clear indication those issues exist.
  - qudat 5mo ago
    I don’t understand: just use an agent to find all memory leaks and segfaults. I don’t get the argument if you are gonna vibe code anyway. With unlimited tokens make it a lint rule or auto formatter.
    - duggan 5mo ago
      LLMs are a force multiplier, not magic. They benefit from good tooling.
      - qudat 5mo ago
        Literally the model “mythos” is being marketed towards finding these exact type of bugs used for exploitation. I really don’t understand the argument: are agents not good at findings memory management issues? What’s the gap?
- dmd 5mo ago
  You want a better source than the actual author of Bun?
  - nesarkvechnep 5mo ago
    Authors can't exaggerate? Maybe some actual numbers can convince people.
    - frde_me 5mo ago
      The cool thing is the author doesn't actually have to convince anyone
    - nicce 5mo ago
      Here: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20%22Segmentation%20fault%22 https://github.com/oven-sh/bun/issues?q=is%3Aissue%20%22Segm... Around 2500 issues with segmentation fault.
      - shpx 5mo ago
        As compared with 41 for deno https://github.com/denoland/deno/issues?q=is%3Aissue%20%22Segmentation%20fault%22 https://github.com/denoland/deno/issues?q=is%3Aissue%20%22Se... With the total number of issues being 16,458 for bun and 14,259 for deno.
- dminik 5mo ago
  Not that it's a particularly accurate stat, but: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3... 119 open, 885 closed https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/denoland/deno/issues?q=is%3Aissue%20state... 10 open, 46 closed
leecommamichael 5mo ago
Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?
- aystatic 5mo ago
  > Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.
  - mort96 5mo ago
    It's not hallucination, it's a basic extrapolation. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" is the same statement as "using Zig resulted in Bun having an extremely high amount of crashes/memory bugs". It is then natural to ask whether their position is "using Zig results in an extremely high amount of crashes/bugs" in general.
    - skybrian 5mo ago
      It's generalizing from Bun (which might be especially tricky code) to other software that might not have the similar issues. There are lots of different kinds of software.
    - aystatic 5mo ago
      That's a hell of a lot more than "basic extrapolation." You're misrepresenting the original claim to fight against one that's trivially easy to dispute. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" (which unlike Rust, doesn't prevent you from writing them) is a completely different statement than your "using Zig results in an extremely high amount of crashes/bugs." Implying that such a generalization was even on the table is insulting. Yes, obviously you can write high-quality software in Zig. But does Zig categorically reject the kind of bugs Bun was suffering from? Rust does.
ozgrakkurt 5mo ago
[flagged]
- wallstop 5mo ago
  Ah, yes, the "you're holding it wrong" defense. If one tool has a higher safety rating than another, significantly so, preventing entire classes of mistakes from happening that the other does not, in a kind of superset manner - even the most skilled craftsman will inevitably make mistakes that would have been prevented by the safer tool.
  - __loam 5mo ago
    [flagged]
    - staticassertion 5mo ago
      Yes, but you really have to go out of your way to segfault/ run afoul of memory safety issues, which are a pain in the ass to debug.
- bergheim 5mo ago
  Not sure if ghostty is the best example https://mitchellh.com/writing/ghostty-memory-leak-fix https://mitchellh.com/writing/ghostty-memory-leak-fix
- f311a 5mo ago
  I think the main problem with Bun is that they are trying to move very quickly. Tigebeetle devs spend 90% time working on stability, safety, tests and so on. They don't need new features, they need reliable software. Their database is pretty simple in terms of features and their goal was always stability and speed. Bun devs spend the majority of the time adding new features.
  - __loam 5mo ago
    Maybe they should put more consideration towards quality if they have a ton of memory issues.
esjeon 5mo ago
Last time i checked their issue tracker (in 2025), the main source of problem was the engine, not their Zig code. A lot of core dump was happening inside and around JSC.
- mawadev 5mo ago
  I remember back in the day we used to blame the user and not the tool, but I guess we changed that notion when it comes to tool vs tool comparisons LOL
energy123 5mo ago
Can you or someone shed some light on how much compute it took to do this?
lionkor 5mo ago
> Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.
- piker 5mo ago
  Yes, liberal unsafe code makes in Rust it arguably worse than writing it in a presumed-unsafe language.
- boxed 5mo ago
  From what I understand, rust "unsafe" is actually pretty damn safe compared to an actually memory unsafe language.
  - IshKebab 5mo ago
    Not really. In fact unsafe Rust is widely considered to be significantly harder to get right than C or Zig. E.g. see https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ or https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ The saving grace is that in idiomatic Rust code you have very little unsafe code - usually none. But yeah there's no way I would trust AI to get unsafe Rust right.
  - lionkor 5mo ago
    It's unsafe

chris_st 5mo ago

And they're clearly marked as `unsafe`, so easy to find, which gives them a nice list of issues to address.

mi_lk 5mo ago

> Bun has had an extremely high amount of crashes/memory bugs Any stats/source? Not that I think it's false > and the ugly parts look uglier (unsafe) which encourages refactoring. Looks like Bun owes that to itself to some extent, not solely because of the language

enricozb 5mo ago
I believe the author is the creator of Bun.
- brazukadev 5mo ago
  Is he working for Anthropic now?
  - danaw 5mo ago
    anthropic bought bun recently
    - brazukadev 5mo ago
      That's exactly my point. The fact they created Bun does not mean they will do what's better for Bun and the people using it.
Ygg2 5mo ago
If you look at percent of segfault errors in each repo, Bun had a much larger percent. Although don't quote on me.
afavour 5mo ago
FTA: > why: I am so tired of worrying about & spending lots of time fixing memory leaks and crashes and stability issues. it would be so nice if the language provided more powerful tools for preventing these things. Not a hard number obviously but a clear indication those issues exist.
- qudat 5mo ago
  I don’t understand: just use an agent to find all memory leaks and segfaults. I don’t get the argument if you are gonna vibe code anyway. With unlimited tokens make it a lint rule or auto formatter.
  - duggan 5mo ago
    LLMs are a force multiplier, not magic. They benefit from good tooling.
    - qudat 5mo ago
      Literally the model “mythos” is being marketed towards finding these exact type of bugs used for exploitation. I really don’t understand the argument: are agents not good at findings memory management issues? What’s the gap?
dmd 5mo ago
You want a better source than the actual author of Bun?
- nesarkvechnep 5mo ago
  Authors can't exaggerate? Maybe some actual numbers can convince people.
  - frde_me 5mo ago
    The cool thing is the author doesn't actually have to convince anyone
  - nicce 5mo ago
    Here: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20%22Segmentation%20fault%22 https://github.com/oven-sh/bun/issues?q=is%3Aissue%20%22Segm... Around 2500 issues with segmentation fault.
    - shpx 5mo ago
      As compared with 41 for deno https://github.com/denoland/deno/issues?q=is%3Aissue%20%22Segmentation%20fault%22 https://github.com/denoland/deno/issues?q=is%3Aissue%20%22Se... With the total number of issues being 16,458 for bun and 14,259 for deno.
dminik 5mo ago
Not that it's a particularly accurate stat, but: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3... 119 open, 885 closed https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/denoland/deno/issues?q=is%3Aissue%20state... 10 open, 46 closed

leecommamichael 5mo ago

Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? There is a lot of quality stuff made with C/C++, so what is Zig doing wrong?

aystatic 5mo ago
> Is your claim that using Zig ends in an "extremely high amount of crashes/memory bugs?" Wouldn't that mean that it isn't even feasible to make high-quality software with such a tool? What caused you to hallucinate such a broad blanket statement? The point is the memory unsafety issues they ran into would be categorically impossible in safe Rust, which is why they're doing this in the first place.
- mort96 5mo ago
  It's not hallucination, it's a basic extrapolation. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" is the same statement as "using Zig resulted in Bun having an extremely high amount of crashes/memory bugs". It is then natural to ask whether their position is "using Zig results in an extremely high amount of crashes/bugs" in general.
  - skybrian 5mo ago
    It's generalizing from Bun (which might be especially tricky code) to other software that might not have the similar issues. There are lots of different kinds of software.
  - aystatic 5mo ago
    That's a hell of a lot more than "basic extrapolation." You're misrepresenting the original claim to fight against one that's trivially easy to dispute. "Bun has had an extremely high amount of crashes/memory bugs due to them using Zig" (which unlike Rust, doesn't prevent you from writing them) is a completely different statement than your "using Zig results in an extremely high amount of crashes/bugs." Implying that such a generalization was even on the table is insulting. Yes, obviously you can write high-quality software in Zig. But does Zig categorically reject the kind of bugs Bun was suffering from? Rust does.

ozgrakkurt 5mo ago

[flagged]

wallstop 5mo ago
Ah, yes, the "you're holding it wrong" defense. If one tool has a higher safety rating than another, significantly so, preventing entire classes of mistakes from happening that the other does not, in a kind of superset manner - even the most skilled craftsman will inevitably make mistakes that would have been prevented by the safer tool.
- __loam 5mo ago
  [flagged]
  - staticassertion 5mo ago
    Yes, but you really have to go out of your way to segfault/ run afoul of memory safety issues, which are a pain in the ass to debug.
bergheim 5mo ago
Not sure if ghostty is the best example https://mitchellh.com/writing/ghostty-memory-leak-fix https://mitchellh.com/writing/ghostty-memory-leak-fix
f311a 5mo ago
I think the main problem with Bun is that they are trying to move very quickly. Tigebeetle devs spend 90% time working on stability, safety, tests and so on. They don't need new features, they need reliable software. Their database is pretty simple in terms of features and their goal was always stability and speed. Bun devs spend the majority of the time adding new features.
- __loam 5mo ago
  Maybe they should put more consideration towards quality if they have a ton of memory issues.

esjeon 5mo ago

Last time i checked their issue tracker (in 2025), the main source of problem was the engine, not their Zig code. A lot of core dump was happening inside and around JSC.

mawadev 5mo ago
I remember back in the day we used to blame the user and not the tool, but I guess we changed that notion when it comes to tool vs tool comparisons LOL

energy123 5mo ago

Can you or someone shed some light on how much compute it took to do this?

lionkor 5mo ago

> Of course, if Bun's Rust port has tons of `unsafe`, it won't magically solve them all, but it'll still get better You get very few of the Rust guarantees when you litter your code with unsafe to get around the safety checks (which is what they're doing here). I would not recommend running this in production.

piker 5mo ago
Yes, liberal unsafe code makes in Rust it arguably worse than writing it in a presumed-unsafe language.
boxed 5mo ago
From what I understand, rust "unsafe" is actually pretty damn safe compared to an actually memory unsafe language.
- IshKebab 5mo ago
  Not really. In fact unsafe Rust is widely considered to be significantly harder to get right than C or Zig. E.g. see https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ https://chadaustin.me/2024/10/intrusive-linked-list-in-rust/ or https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ https://lucumr.pocoo.org/2022/1/30/unsafe-rust/ The saving grace is that in idiomatic Rust code you have very little unsafe code - usually none. But yeah there's no way I would trust AI to get unsafe Rust right.
- lionkor 5mo ago
  It's unsafe