- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
- cross-posted to:
- [email protected]
- [email protected]
- [email protected]
You must log in or # to comment.
This Rust rewrite would’ve taken a team of engineers with full-context on the codebase a year of work
Doubt.
I mean it was 600,000 lines of Zig prior to the rewrite yea? If we say that a team is ~6 people, that’s 100,000 lines each to read through and translate. Assuming 250 working days in a year, that’s 400 lines of code you just need to read every day, let alone the Rust you need to be writing (approximately another 400 lines).
Add to that overhead for planning and coordination… I actually think a year for a team might be an underestimate.
Zig’s features don’t map 1:1 to Rust’s features, so translating line-by-line (or file-by-file) doesn’t even make much sense. What are you supposed to do with a crazy comptime function full of reflection when translating that? What about custom pointer types (which Bun had to create for Rust), lifetimes, differences in ecosystem library APIs, etc?
The author actually mentions the challenges they ran into due to breaking the code up across multiple crates. They needed to break cyclic dependencies for it all to compile.
I agree. 1 year is an underestimate.
https://andrewkelley.me/post/my-thoughts-bun-rust-rewrite.html
Commentary/blog post by Andrew Kelley (Zig creator) for perspective!
Very interesting achievement, and of course requires domain knowledge to implement (which you can’t get without experience!)
This should definitely be required follow-up reading, as it puts many of the Bun article’s “too good to be true” claims into context.
The fact that the Bun author didn’t know that Zig also has LTO really puts the rest of their claims into question.
Honestly, if this is tge future for software engineers, I’ll leave the fields when I ma forced to do it.
