[endospore]

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.

[insanitybit]

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.

From my perspective.

1. 128 known bugs were fixed.

2. 237 potential bugs were made grep'able.

That is a massive win to me.

[endospore]

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

[insanitybit]

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

[endospore]

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.

[insanitybit]

> There are no such invariants in Zig.

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.

[endospore]

> Zig does have invariants

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.

[endospore]

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.

[insanitybit]

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

[endospore]

Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically.

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