endospore
For example applying the recover file (well it's a huge pitfall in vim on its own) resets not only the current undo history but also the "persistent" one.
They can't mention what they don't know. And that's the exact reason I'm against this: doing a port without being able to tell what is correct is asking for a disaster, obviously.
I've checked their posts and blogs for a few times, and I'm quite sure they don't know any of these to write about them.
> the 1.4 version has not been released yet
Let's hope the repeated delays (it was scheduled for last week) are not for quality issues, otherwise I'll only be half correct. It appears that all the MIRI errors are not stopping them though. (They have a script to run it but most probably it just fails and they don't care. Personally I'm not executing any of bun's code to avoid summoning nasal demons, so I actually don't know for sure)
> get rid of the unsafe block
Would be possible if they are not disregarding everything else going for numbers. E.g. they are actively increasing the unsafe surface by rewriting some code in SIMD C++ (https://github.com/oven-sh/bun/pull/33032). As if no Rust solutions already exist.
> Still easier than the Zig version
Well, this is true but only realizable if they know how to deal with the new problems emerging during the process. My current conclusion is that they don't.
> ideological
For me it's methodological as explained above.
That being said I've found a case that doesn't do much harm even if it's fixed, and is technically not my contribution. You may take a look at that:
Personally I chose not to disclose my findings in public to avoid this kind of outcome. Having a good laugh with others is not as important as keeping the result of this experiment undisturbed.
This also eliminates the chance of another round of marketing of LLM ability based on actual human contributions and I suggest everyone who is able to analyze the code to do the same - so that they cannot misattribute our ability to LLMs.
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.
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.
Given that they are investing their time into actually learning the language before diving into this mess. No, unsafe Rust isn't supposed to be something you can handle without prior knowledge.
Jarred was even asking in public how to use traits without runtime overhead during the rewrite. And the blog post phrased it like a normal problem to encounter while doing a million lines port... That's two months after the initial rewrite so you can guess if they learned.
I'd also like to inform you that
- the current success metrics solely consist of their advertisement, my eyes looking at the code strongly suggest otherwise
- the Bun team lacks knowledge to actually make it more idiomatic: none of the Bun team has written any Rust and relying on model knowledge is already proven insufficient.
The release decision itself is presumably driven by that tbh. It's only LGTM from there when nobody knows how to review unsafe Rust.
> 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.
True.
> has fewer bugs
Nope, this is demonstrably false because Rust has its own invariants around its types and the codebase is violating a lot of them.
> every potential memory issue is neatly annotated by an unsafe block
"Potential memory issue" can originate in unsafe blocks and safe code that are able to alternate the input condition of these unsafe blocks. Guess what? That still counts towards 100% in this code base, hence the abomination remark.
> refactor them out one by one
Not as easy as it sounds. They are like threads in a yarn ball, if there are one or two ends visible it's easier to sort them out. The actual situation is more like we have tens of thousands of ends (all the raw pointer code that comes with every shared object), to fix them it's basically a requirement to unwind the whole thing (rewrite all the callees and reorder the data flow as needed, redesigning all the APIs during that).
It's too early to declare it as anything remotely close to a win, optimistically saying.
You can tell what will happen when they release it before sorting out all the new bugs introduced by the not-exactly-line-by-line port.
Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.
Can't help laughing at this point.
They are going to release the "intermediate step" with all its issues as v1.4. I think that says a lot about which party is ignoring facts. (hint: not me, not you, not Andrew)
> The “unsafe” part is also confusing
They are right in this case. The code base contains thousands of the most unsafe unsafe blocks I've ever seen in Rust.
We often ensure a project holds water against miri. This one doesn't even pass for clippy.
That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims that may mislead someone else.
https://doc.rust-lang.org/nomicon/working-with-unsafe.html
I'm not even trying to prove any point since the beginning. Can't do that when you have a different definition of bug from others.
Please if you are going to reply to this ever again try stop making any claims. Otherwise I'm afraid that it will continue into infinity.
Not these in particular. You are again ignoring the context.
> Undefined behavior does not mean a bug can be triggered.
Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
https://predr.ag/blog/falsehoods-programmers-believe-about-u...
> `unsafe` is grep'able, hence all memory safety bugs are grep'able.
Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.
Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.
Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.
Please READ. Including the one I've added at slightly higher layers of replies.
> who says that the same invariants weren't broken on the Zig side
There are no such invariants in Zig.
> "unsafe invariant broken" does not strictly mean that there's a reachable bug.
Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
> callers may never actually trigger a bad invariant in an unsafe block.
There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
> potential, grep'able bugs
We are indeed going in circles but I have to ask: you still don't understand that? Grep works for violated lints, unsafe blocks and all things explicitly exist in the code. Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools. They also have thousands of those. It's unfair to say the unsoundness is freshly introduced by the port, but Rust also doesn't help in this way where no unsafety is encapsulated and calling anything can be a wild ride.
> pointer aliasing is undefined behavior in both languages
That included and also basically every other claim in that comment. I'd be happy to learn otherwise if you have concrete evidence.
[Edit: erased information that can help people find the bugs without prior knowledge]
> I haven't said that you have to provide evidence of them
Sure, but if I'm going to it would be a lot easier to convince everyone how bad it is (just like I did in private message groups). I can't take the risk that "everyone" also includes Jarred though.
> you can grep for these bugs now
You can grep for the greppable new bugs. I raised them as an argument because these issues are glaring. What about the ungreppable ones? More than half (again, randomly sampled) unsafe usage in the 10,413 unsafe blocks in current Bun looks iffy to me. I just haven't taken the time to verify them because many requires reasoning across the code base (see? the exact problem Rust ought to prevent). From a Rust point of view it's a huge failure.
All these while considering that the Bun agents (no people at this point I'm afraid) don't even know how to grep for the easy ones.
> ~2X potential
at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance.
And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough.
Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
- They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SAFETY comments in code.
- I only spent ten minutes and found two code patterns that are wrong with little exceptions. Also randomly checked a few samples and there was no exception. This basically means that failure patterns not explicitly picked and disallowed will repeat themselves over and over. Try imagine the more subtle ones hiding in this huge codebase.
- Trivial to find != Trivial to fix. 107 of the problems (one of the categories) are borrow issue and requires large refactoring (rearrange and rethink whole modules of code) to be removed completely.
So yes, huge regression by my standards. And I'm not questioning Rust the language. I'm questioning Claude, Jarred the person, their dev & marketing practice and the Bun project.
Btw these categories are separate from the (still unfixed) category of problems I mentioned 54 days ago in the comments before.
And for the emotional aspect. I'm working as an R&D engineer and one of my recently assigned experiments is to evaluate replacing workers with LLMs, quality software with slops. Every bit of exaggeration they make is making my coworkers lose jobs and I'll be no exception. The entirety of me consists of reasons going against this kind of marketing compaign.