| |
| ▲ | rane a day ago | parent | next [-] | | "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. | | |
| ▲ | endospore a day ago | parent [-] | | "Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process. Can't help laughing at this point. | | |
| ▲ | mpyne a day ago | parent | next [-] | | 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. | | |
| ▲ | endospore a day ago | parent [-] | | The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preserving transformation" without new UBs looks like. |
| |
| ▲ | pylotlight 11 hours ago | parent | prev [-] | | You didn't read the blog post at all did you? Clearly you have zero clue what you are talking about. | | |
| ▲ | endospore 10 hours ago | parent [-] | | Sorry, I did. And I did an internal sharing with respect to the blog post, on topics of how to (and not to) do software migration, how (not) to deal with unknown unknowns etc. We have several ongoing software (automated) migration projects so I did rather extensive research around it. I do regret that I've also read the code though, otherwise I'd probably live a little happier with ignorance right now. Sadly as they don't know they don't know about the issues, there's no indication of those in the two public materials they have released. |
|
|
| |
| ▲ | uecker a day ago | parent | prev | next [-] | | 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. | |
| ▲ | Dylan16807 a day ago | parent | prev [-] | | Surely a lot of review has happened in the last two months? | | |
| ▲ | endospore a day ago | parent [-] | | 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. | | |
| ▲ | Tadpole9181 a day ago | parent [-] | | 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? | | |
| ▲ | ambicapter a day ago | parent | next [-] | | What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust? | | |
| ▲ | Tadpole9181 a day ago | parent | next [-] | | It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly, covered and have an avenue for remediation. I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good? Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done. | | |
| ▲ | fleventynine 21 hours ago | parent [-] | | I like Rust and use it full-time professionally. Unsafe is not the same as unsound. Unsound means that the unsafe code is not maintaining the aliasing invariants on references required by the language, and thus undefined behavior can leak into safe code (that is, the safe code can be miscompiled). Known unsound code should not be merged, let alone released to production. If you have good enough tests and run them under MIRI or ASAN, maybe you can get away with it for a time, but most Rust experts would not sign-off on such a project. If somebody put a gun to my head and told me to make the best of such a codebase, I would try to figure out how to turn off the LLVM optimizations that assume the Rust references don't alias. With these optimizations this codebase is scarier than most C or C++ code. |
| |
| ▲ | skydhash a day ago | parent | prev [-] | | I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis. |
| |
| ▲ | endospore a day ago | parent | prev [-] | | My conclusion was formed in my two months long tracking of the repo activities. They have done absolutely nothing in that front. (Well, to be precise they tried to fix exactly one thing that was pointed out but that's it) > must interface with C code that has no safe interface Yeah so the sane first step is to create encapsulated, safe interface for them, especially in a project like this. Deno for instance have ~0.2x as many unsafes. And mind you if you haven't read the code, the vast majority of unsafe blocks in bun are for raw pointer access to local (Rust) objects because their ownership was a mess both before and after the rewrite. Also funnily enough a lot of the access patterns are wrong (in the Rust sense), leading to hundreds of new undefined behaviors. > be honest and reasonable Well, well. Talking about dishonest and unreasonable behavior, why is bun releasing a new version before solving any of those glaring issues? I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability. | | |
| ▲ | lunar_mycroft 21 hours ago | parent | next [-] | | > Deno for instance have ~0.2x as many unsafes. Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code). | |
| ▲ | Tadpole9181 a day ago | parent | prev [-] | | > I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability. Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching. I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception. > Deno for instance have ~0.2x as many unsafes. A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is. | | |
| ▲ | endospore 18 hours ago | parent [-] | | > nobody has really pointed to a single actual issue I personally know 3 categories of newly introduced issues spanning the code base with 200+ occurrences, that leads to undefined behavior and memory issues. Not doing any contributions to the code is my conscious decision, which includes not pointing to the specific problems in public. It's nice to hear that people are doing the same. |
|
|
|
|
|
|
