> Couldn't a case be made that it's better to get Bun to the to the language with the stronger type system first and, once there, use that stronger type system as leverage for these kinds of improvements as a follow-on effort? It seems preferable to requiring perfection on the very first step.

This is what they are doing.

They are working through the issues as they come in.

They'll just need to update the prompt with "make sure there's no UB", and it should be good.

Yes, and seems pretty clear you can now backpressure the rewrite with tools like miri to have Claude Code automatically improve it.

It's not surprising that a mostly straightforward translation to (partly unsafe) Rust exhibits UB.

What is a bit disappointing is that the Rust code apparently has APIs that aren't marked unsafe but may cause UB anyway. When doing this kind of translation, I'd always err on the side of caution and start by marking all/most things unsafe. Or prompt the slopbots to do the same I guess.

Then you can go in and verify the safety of individual bits step by step.

From what I read from the PR comments, the case is that the unsafe blocks behave in a way that allows for UB.

This is expected, because unsafe rust can leave your program in an unhealthy state, since the language doesn't doesn't hold your hand anymore.

The point is that at a minimum you're supposed to bubble the `unsafe` up if the API does not guarantee safety is maintained for all cases (and documents the invariants that have to be kept by the caller), otherwise the system breaks down.