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:

https://github.com/oven-sh/bun/pull/30794

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.