Hacker News Reader

Comment by pesnk | Hacker News Reader

That kind of error was expected. I don't see it as an issue against the rewrite. They kept the stable versions on Zig in case ppl needs stability. Eventually, the errors will get fixed.

View on HN

That kind of error was entirely avoidable. There are well-known tools in the Rust ecosystem that detect this kind of error and while the tools do not detect all instances of UB caused by mistakes in unsafe blocks, it's still considered good practice to run them.

Indeed this was caught by a well-known tool, Miri, that detected this error.

>There are well-known tools in the Rust ecosystem that detect this kind of error

Yes, tools like Miri, which this very post is about.

Indeed. My point is that just using the standard tools in the Rust ecosystem - like miri - would have trivially uncovered this error before it made it to the mainline.

This is an engineering choice: do you merge first and then fix the remaining issues or do you get everything perfectly clean first and then merge?

I've seen large rewrites and migrations take both approaches -- in my experience, the former usually works out better.

In any practical application there'll be a known set of errors and I'm generally fine merging code that has known deficiencies. But personally, I'd not condone merging anything that causes UB. It undermines such a fundamental guarantee of the language that it should be detected and eliminated. And bun certainly rises to the level of software where I'd expect that the project runs all available tooling to detect such cases. Especially if you LLM - code it. "Do not cause UB" should be part of the test harness.

I think the point is you should probably run that tool and fix all the issues _before_ merging into the master branch.

Reply on news.ycombinator.com