From Newsgroup: comp.programming
In article <
bun-20260713102858@ram.dialup.fu-berlin.de>,
Stefan Ram <
ram@zedat.fu-berlin.de> wrote:
[snip]
| Despite fears that the automated port would result in "AI slop," the
| performance metrics for the Rust-backed Bun v1.4.0 have proven highly
| successful:
|
[...]
|
| "Unsafe" Rust Concerns Early code leaks showed a heavy reliance on
| static mut and thousands of unsafe blocks to preserve Zig's original
| raw pointers, leading to arguments over whether the code is truly safe
| or idiomatic.
[snip]
The bigger problem, pointed out externally, was not the use of
`unsafe` (that can be ok), but rather that the rewrite had
multple prominent instances of unsound memory accesses, and
villated violating the _language's_ rules and memory safety
generally. Critically, many were easily triggered from _safe_
Rust code; this is supposed to be a compile-time error.
People misunderstand what "unsafe" means in Rust: it does not
mean you can do whatever you want. It merely means that the
responsibility for upholding the invariants required by the
language shifts to the programmer, who for some reason knows
that a given construct does not violate the language's rules,
while the compiler cannot infer this. The Bun port ignored
this, in part because the Bun authors (by their own admission)
did not know Rust when they started. It's telling that they did
not even bother to have an agent run the test suite with `miri`,
which might have detected many of the problems.
Does the rewrite "work", in so far as the bun test suite passes?
Yes. Will it silently break and stop working on a minor
toolchain update? Probably, also yes.
Note that this also speaks to the limitations of testing, and
far from being a success story of LLM use, is actually a good
example of AI slop.
- Dan C.
--- Synchronet 3.22a-Linux NewsLink 1.2