I think that there are several points in the article.
1. Bun had quality issues. The quality issues were known to the Zig maintainers because Bun was one of the most popular and biggest projects using Zig so they were closely monitoring it.
2. The Zig maintainers considered the quality of the Bun codebase itself not good (but it's also true that typically implementors of programming languages have high expectations for code quality).
3. Bun has been rewritten in Rust using Claude
4. The fact that the test suite for Bun passes now that the code has been rewritten does not guarantee a better quality, because the coverage of such test suite was not enough in the first place to detect the quality issues when the code was manually written in Zig. So how can it be sufficient now to certify the code quality of the Rust rewrite?
Comments
I think that there are several points in the article.
1. Bun had quality issues. The quality issues were known to the Zig maintainers because Bun was one of the most popular and biggest projects using Zig so they were closely monitoring it.
2. The Zig maintainers considered the quality of the Bun codebase itself not good (but it's also true that typically implementors of programming languages have high expectations for code quality).
3. Bun has been rewritten in Rust using Claude
4. The fact that the test suite for Bun passes now that the code has been rewritten does not guarantee a better quality, because the coverage of such test suite was not enough in the first place to detect the quality issues when the code was manually written in Zig. So how can it be sufficient now to certify the code quality of the Rust rewrite?