Comment by Matl
8 days ago
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
8 days ago
I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).
"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.
"Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process.
Can't help laughing at this point.
I don't know, did the prior vibe-coded Zig code not ever have pointers aliased to data? Might be preserving semantics too well, if anything.
1 reply →
You didn't read the blog post at all did you? Clearly you have zero clue what you are talking about.
1 reply →
Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.
Surely a lot of review has happened in the last two months?
Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated.
Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
This feels like such an absurd, bad faith take I keep hearing.
In Zig, every single memory operation is unsafe.
And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors.
There's too much, sure, but can we at least be honest and reasonable?
8 replies →