endospore

In the rewrite blog post

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.

Aw I feel quite sorry for using the word "demonstrable" while not intending to demonstrate anything, in order to avoid any contributions to the project. I apologize for that.

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

https://github.com/oven-sh/bun/issues/30719#issuecomment-446...

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.

Sorry, I did. And I did an internal sharing with respect to the blog post, on topics of how to (and not to) do software migration, how (not) to deal with unknown unknowns etc. We have several ongoing software (automated) migration projects so I did rather extensive research around it.

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.

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.

Good engineers can work in any language

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.

That's a stated goal, so nope. But releasing it before any cleanups is another story.

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.

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.

The Zig one uses raw pointers. These are bad and get out of hand quickly but at least don't have constraints like "you must never have two &mut on the same value". You may refer to c2rust to see how "semantics preserving transformation" without new UBs looks like.

Their (public) project management is horrible, you can find fixed issues unclosed and unfixed issues closed. Not really surprising when that part of the work is completely taken over by LLM agents though.

The original code was one giant unsafe block

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.

next step is to make it idiomatic rust

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.

Reviewing is meaningless while they are still keeping the 10433 (sorry it has become 10503 since last week) unsafe blocks, most unsound and none encapsulated.

Any review would get to the simple conclusion that this should not be released before all the obvious bads are sorted out.

"Preserving semantics" by casting pointers to aliasing refs in Rust, ignoring lints and errors in the process.

Can't help laughing at this point.

ignoring the fact that it was an intermediate step.

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.

Yes, they have introduced (at least) several times more memory safety issues by violating the rust specific rules. Check how most of their unsafe blocks are unsound and worse, how many are straight up incorrect with a total bs // SAFETY above it, leaving no sensible usage without invoking UB.

We often ensure a project holds water against miri. This one doesn't even pass for clippy.

increasingly dumb

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.

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.

Oh it's so nice of you when I've spent the bottom half of my comment explaining how you cannot grep for most of them in this BAD codebase.

Please READ. Including the one I've added at slightly higher layers of replies.

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.

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.

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.

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.

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.

Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.

Look a few more till you find absolutely bs SAFETY comments marked on immediate UBs. They are everywhere.

Well the rewrite has newly introduced many immediate and critical safety (as in Rust sense) problems. It's clear and obvious if you read the code knowing the basic rules of unsafe Rust. And don't be surprised if it doesn't appear as obvious to you or Jarred or Claude, because not knowing they don't know is the exact reason why they failed at it.

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.

Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.

And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swept away (not even treated as unsoundness), if you actually look at the code and the summary.

No. They introduced quite a few aliasing issues that result in immediate UB in Rust but are allowed in Zig. I skimmed over the unsafe blocks with rg for ten minutes and spotted like 3 cases and these wouldn't exist in the original code.

Also the LLM is inventing ways to get around borrow checker limitations with unsafe which is also concerning. But I didn't verify if they are UB or not (either way it's a rejection if I'm to review the code).

Calling it as working is a bit of an exaggeration. Looked at the code for a few minutes I'd expect it to crash and burn if they ever dare to turn the optimization on.