3 ms·

It's a transpile. And not even a good one. The generated code is far from idiomatic rust. Some may consider it an abomination.

alexandra_au 3mo ago
grep -nr 'unsafe' . Is all you need to know to consider how much of an abomination it is
- simonw 3mo ago
  This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10: 2026-05-14 23427db 13907 2026-05-14 19d8ade 13861 2026-05-15 4d443e5 13840 2026-05-17 172afa5 13803 2026-05-17 80a06a8 13849 2026-05-18 fba43af 14026 2026-05-19 303cd28 14052 2026-05-20 21db682 14243 2026-05-22 a06a00a 14239 2026-05-23 49c97de 14090 2026-05-28 472a06a 14076 2026-06-01 a0d1472 14071 2026-06-04 8553428 14032 2026-06-09 717542f 14053 2026-06-10 1c90e5a 14043 2026-06-11 6e91d24 14031 2026-06-16 bd8edc7 14086 2026-06-17 6ef5977 14104 2026-06-20 315ed50 14106 2026-06-22 c6be834 14120 2026-06-23 ea7e44f 14108 2026-06-23 03042ab 14128 2026-06-29 86d32c8 14046 2026-07-01 6640fcf 14077 2026-07-04 51074e3 14099 2026-07-06 9d0e93d 14186 2026-07-08 ab6eb2d 13953 2026-07-09 86caf6e 13936 2026-07-10 91675d0 13930 2026-07-13 73b6c14 13951 2026-07-16 4bbe075 13978 2026-07-16 57e30a5 13995 So not as much cleanup as I had expected! ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb2d0 https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
- rwz 3mo ago
  The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had. Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence. All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
  - endospore 3mo ago
    > The original code was one giant unsafe block True. > has fewer bugs Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them. > every potential memory issue is neatly annotated by an unsafe block "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark. > refactor them out one by one Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that). It's too early to declare it as anything remotely close to a win, optimistically saying.
    - d5lt5 3mo ago
      For someone who is not a rust dev, would you mind giving me an example of this: "Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
      - endospore 3mo ago
        Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that. That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that: https://github.com/oven-sh/bun/pull/30794 https://github.com/oven-sh/bun/pull/30794
      - LtWorf 3mo ago
        An "unsafe" in rust is like an axiom in mathematics. You can use to prove higher level theorems but it has to make sense. The second that you start to introduce nonsensical axioms (or bugs in unsafe sections) all your proven correct theorems will be worthless.
brabel 3mo ago
Can you show some examples of abominable Rust code they have?
amelius 3mo ago
Why not transpile directly into LLVM IR?
- deleted 3mo ago
  [deleted]
- jqbd 3mo ago
  I don't think AI or humans are trained well on it.
daishi55 3mo ago
Seems to be working just fine though? And like, this is just the beginning of the port. They did a mechanical port basically line by line, next step is to make it idiomatic rust. I thought by now people would’ve learned to stop betting against this rewrite.
- cube00 3mo ago
  > Seems to be working just fine though? As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it. The existing community is now either going to need to learn Rust or new Rust developers are going to have to join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.
  - daishi55 3mo ago
    historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”. This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
    - benrutter 3mo ago
      > historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”. I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher. LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code. The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"
brown9-2 3mo ago
Is it important to be idiomatic if the project meets its goals around memory safety?
- feverzsj 3mo ago
  If it's not idiomatic, the memory safety won't be guaranteed.
- kikimora 3mo ago
  No, but the project does not meet its goals around memory safety. It is usage Rust all the way down with same memory safety issues.
variadix 3mo ago
Yeah I don’t understand this port at all other than as a big marketing stunt. It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.
luckydata 3mo ago
given enough time and tokens, it will become that. I really don't understand how that is a problem in any way.
vips7L 3mo ago
LLM code has always been an abomination.
deleted 3mo ago
[deleted]

alexandra_au 3mo ago

grep -nr 'unsafe' . Is all you need to know to consider how much of an abomination it is

simonw 3mo ago
This comment inspired me to take a look at the trend of "unsafe" in the Bun code over time since the rewrite PR first landed - here are the commits where that number changed by at least 10: 2026-05-14 23427db 13907 2026-05-14 19d8ade 13861 2026-05-15 4d443e5 13840 2026-05-17 172afa5 13803 2026-05-17 80a06a8 13849 2026-05-18 fba43af 14026 2026-05-19 303cd28 14052 2026-05-20 21db682 14243 2026-05-22 a06a00a 14239 2026-05-23 49c97de 14090 2026-05-28 472a06a 14076 2026-06-01 a0d1472 14071 2026-06-04 8553428 14032 2026-06-09 717542f 14053 2026-06-10 1c90e5a 14043 2026-06-11 6e91d24 14031 2026-06-16 bd8edc7 14086 2026-06-17 6ef5977 14104 2026-06-20 315ed50 14106 2026-06-22 c6be834 14120 2026-06-23 ea7e44f 14108 2026-06-23 03042ab 14128 2026-06-29 86d32c8 14046 2026-07-01 6640fcf 14077 2026-07-04 51074e3 14099 2026-07-06 9d0e93d 14186 2026-07-08 ab6eb2d 13953 2026-07-09 86caf6e 13936 2026-07-10 91675d0 13930 2026-07-13 73b6c14 13951 2026-07-16 4bbe075 13978 2026-07-16 57e30a5 13995 So not as much cleanup as I had expected! ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb2d0 https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
rwz 3mo ago
The original code was one giant unsafe block with almost no tangible way to find or debug all the subtle memory bugs and leaks they had. Now it's smaller, faster and has fewer bugs. Also its every potential memory issue is neatly annotated by an unsafe block so you can go and refactor them out one by one with confidence. All this seems like a pretty huge improvement to me. Why is this an abomination in your eyes?
- endospore 3mo ago
  > The original code was one giant unsafe block True. > has fewer bugs Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them. > every potential memory issue is neatly annotated by an unsafe block "Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark. > refactor them out one by one Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that). It's too early to declare it as anything remotely close to a win, optimistically saying.
  - d5lt5 3mo ago
    For someone who is not a rust dev, would you mind giving me an example of this: "Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them."
    - endospore 3mo ago
      Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that. That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that: https://github.com/oven-sh/bun/pull/30794 https://github.com/oven-sh/bun/pull/30794
    - LtWorf 3mo ago
      An "unsafe" in rust is like an axiom in mathematics. You can use to prove higher level theorems but it has to make sense. The second that you start to introduce nonsensical axioms (or bugs in unsafe sections) all your proven correct theorems will be worthless.

brabel 3mo ago

Can you show some examples of abominable Rust code they have?

amelius 3mo ago

Why not transpile directly into LLVM IR?

deleted 3mo ago
[deleted]
jqbd 3mo ago
I don't think AI or humans are trained well on it.

daishi55 3mo ago

Seems to be working just fine though? And like, this is just the beginning of the port. They did a mechanical port basically line by line, next step is to make it idiomatic rust. I thought by now people would’ve learned to stop betting against this rewrite.

cube00 3mo ago
> Seems to be working just fine though? As with all transpile ports, the true test will be how well it can be extended and maintained over time. Historically working with the output of a transpile is not pleasant and requires heavy rework to get it to the point where you can be comfortable enough to extend it. The existing community is now either going to need to learn Rust or new Rust developers are going to have to join the project and they may not invested enough to refactor the transpiled output when they could work on something else like Boa.
- daishi55 3mo ago
  historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”. This is I think a preview of the future of software development. LLMs are having the same effect as compilers, frameworks, etc - they are making new kinds of software development feasible which were not previously so.
  - benrutter 3mo ago
    > historically we didn’t have LLMs which don’t mind “unpleasant[ness]” and “heavy rework”. I'm not quite as optimistic. "Unpleasantness" might sound like subjective disgust, but it often relates to objective criteria like complexity, that increases the surface area open to bugs in a real way. Similarly, if reworking has a non-0 chance of bugs, its gonna have some form of risk, and a major one will of course be higher. LLMs may be capable of a lot, and they miggt change what projects people can take on, but they definitely don't write bug free code. The bun rewrite/transpile did use some neat ideas like lots of testing and per-file translations, so hopefully they have more in their toolbox than "LLMs hopefully won't be affected by complexity or write bugs"

brown9-2 3mo ago

Is it important to be idiomatic if the project meets its goals around memory safety?

feverzsj 3mo ago
If it's not idiomatic, the memory safety won't be guaranteed.
kikimora 3mo ago
No, but the project does not meet its goals around memory safety. It is usage Rust all the way down with same memory safety issues.

variadix 3mo ago

Yeah I don’t understand this port at all other than as a big marketing stunt. It would have made far more sense, for reliability, efficiency, cost, etc., every metric really, to use or write a source to source translator that preserves as much structure from the original code as possible. Typically if you do a rewrite there are lessons learned from the existing code base that you want to take into account when doing the rewrite; using a bunch of agents to do the porting file-by-file buys you none of that. In either case the code will be an unidiomatic translation, just with LLMs you get an added source of indeterminism and a huge bill at the end of the month.

luckydata 3mo ago

given enough time and tokens, it will become that. I really don't understand how that is a problem in any way.

vips7L 3mo ago

LLM code has always been an abomination.

deleted 3mo ago

[deleted]