Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #16906

Re: Bun Zig Rust AI rewrite

Path csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups comp.programming
Subject Re: Bun Zig Rust AI rewrite
Date Mon, 13 Jul 2026 09:57:42 -0000 (UTC)
Organization PANIX Public Access Internet and UNIX, NYC
Message-ID <1132cqm$4c8$1@reader1.panix.com> (permalink)
References <bun-20260713102858@ram.dialup.fu-berlin.de>
Injection-Date Mon, 13 Jul 2026 09:57:42 -0000 (UTC)
Injection-Info reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="4488"; mail-complaints-to="abuse@panix.com"
X-Newsreader trn 4.0-test77 (Sep 1, 2010)
Originator cross@spitfire.i.gajendra.net (Dan Cross)
Xref csiph.com comp.programming:16906

Show key headers only | View raw


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.

Back to comp.programming | Previous | Next — Previous in thread | Find similar | Unroll thread


Thread

Bun Zig Rust AI rewrite ram@zedat.fu-berlin.de (Stefan Ram) - 2026-07-13 09:31 +0000
  Re: Bun Zig Rust AI rewrite cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-13 09:57 +0000

csiph-web