It's going to work for the most part. Most people know that. It's a file by file, mostly function by function, conversion from one low level language to another with a very large test suite (with lots of Rust unsafe to work around differences). I've done that for C tools and it's fine, with some obscure edge cases here and there. The challenges are going to be making the new, very ugly, alien codebase idiomatic Rust in future and adding features or debugging the complex issues. I wish the developers luck. They're in for a slog.
replyJust to clarify, you did this for C tools using LLMs or using deterministic conversion tools?
replyI think this is the glimpse of what to come - https://github.com/oven-sh/bun/issues/31463
replyHaving seen some of the diffs, it's already going wrong in my view.
replyIf most of the glaring problems are addressed (massive unsafe usage), and metrics show improvement (less crashes), then did it really go wrong? The fact the code is not idiomatic is less interesting, because that can be addressed incrementally. Let's wait 3 months and reflect.
replyI'm thinking regressions and broken tests. Bun is already known to segfault a lot and their existing tests were rather lackluster, the Rust port being just as unsafe would be the least of their problems.
replyThis assumes that the memory safety bugs in the unsafe Rust port are the same as the Zig codebase. A total rewrite with so little review is virtually guaranteed to introduce many new bugs which very well may be more severe than the old bugs.
replyCurious can you elaborate on this?
replyI think given the novelty of this, a lot of eyes will be on it, so a lot of issues will be dealt with out of the gate. The problem will be when smaller projects that aren't in the spotlight think it's safe too and then do stuff like this after being encouraged by bun, and for those projects then lots of bugs will just remain unfixed. Basically a nation state adversary's wildest dreams came true today.
replyIf that scenario happens it just means the collapse will be slower but still inevitable as anecdotes pile up and reach critical mass of common knowledge.
replyYeah. I'm just suggesting bun won't blow up spectacularly as antiai people are expecting it too.
replyIt will not go wrong in obvious ways, LLMs are actually not that bad for language translation, and they have big test coverage; any issues will be non obvious. The question will be more long term maintainability, how fast will the whole thing collapse.
replyWhy people say they have big test coverage while other say it segfaults a lot? I saw lot of JS test that this is just API surface test. Edge cases happens inside API implementation, things like memory leaks or data corruption that shows up after a while cannot be catched reliably with these tests.
replyI expect it will be just fine. It's like bragging about getting the words right on a mental health exam. AI was given the answer, it just repeated it back in a slightly different format. Even a stupid human could have done that.
reply> AI was given the answer, it just repeated it back in a slightly different format.
replyRidiculous.
How so? The code was already coded, the tests were already coded, the architecture was already in place. Even the help in needed to map some stuff to the new language was already coded. What did AI actually do here?
replyYou know the tests "all pass" because the LLM changed a lot of them, right?
replyThis is especially aggravating because it goes against all engineering principles about reliability and being conservative.
replyThis is more like an ignorant business man's view on technology and engineering. It is not about failing or winning in the bussiness sense but this business man point of view is just despicable from the point of view of an engineer who is trained to do a "good job".
However, you can never prove that it hasn't gone wrong, because there are so many long-form problems with software (quiet bugs, maintainability issues, etc). This creates FUD.
reply