Comment by feverzsj
8 days ago
It's a transpile. And not even a good one. The generated code is far from idiomatic rust. Some may consider it an abomination.
8 days ago
It's a transpile. And not even a good one. The generated code is far from idiomatic rust. Some may consider it an abomination.
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.
> 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.
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.
1 reply →
> next step is to make it idiomatic rust
You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.
Sorry you think they’re not going to continue developing and improving bun and making it more idiomatic?
Given the success of the port so far and the fact that CC is now running on rust Bun, that seems highly unlikely to me.
4 replies →
But Bun did not even release a new version of Bun written in Rust yet. It was still a canary version.
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.
Can you show some examples of abominable Rust code they have?
Why not transpile directly into LLVM IR?
I don't think AI or humans are trained well on it.
Is it important to be idiomatic if the project meets its goals around memory safety?
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.
If it's not idiomatic, the memory safety won't be guaranteed.
grep -nr 'unsafe' .
Is all you need to know to consider how much of an abomination it is
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:
So not as much cleanup as I had expected!
ChatGPT written script for counting here: https://gist.github.com/simonw/b1015bcadcedd1a781cedb7af9cbb...
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?
> 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.
12 replies →
> has fewer bugs
who claimed that? Are you suggesting that the rewrite did not introduce any new bugs? The correct answer is, by the way, that no one knows since it's millions of lines of code no one has properly read.
> smaller, faster
I thought this has already been debunked. You could just write better zig and make it smaller, faster (and have fewer bugs!)
given enough time and tokens, it will become that. I really don't understand how that is a problem in any way.
LLM code has always been an abomination.