| |
| ▲ | 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. |
|
|
|
|
