Can't assume good faith in you at this point but I'll explain it.
- 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.
Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.
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 are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port.
I'm not sure that this is true - who says that the same invariants weren't broken on the Zig side? (Aliased pointers are UB either way, for example). Also, "unsafe invariant broken" does not strictly mean that there's a reachable bug. It should be cleaned up though, obviously. But in theory, callers may never actually trigger a bad invariant in an unsafe block.
Regardless, even assuming that these are genuinely new bugs, it doesn't change my point. Going from ~X known bugs to ~2X potential, grep'able bugs, is a win to me. Sounds like it isn't to you. Great.
> Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
I'm obviously not intentionally ignoring anything, if you think I am then you can stop responding.
There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims.
> 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.
Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.
> Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.
> 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.
Can be, yes.
> Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools
This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating
> ~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.
> And they are actual bugs that I've take extra time to (statistically) verify.
I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them?
> 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.
My false claims? Like that pointer aliasing is undefined behavior in both languages? lol okay?
> 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.
I'm taking all of your claims at face value, I haven't said that you have to provide evidence of them. I'm not saying that your claims are false, I'm saying that I can grant them and still disagree with you.
I don't know what to tell you. Even if you said that those 2x bugs were 100% verified, I'd still say that this is a win because you can grep for these bugs now. That is obviously better to me.
- 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.