endospore

It's more persistent than a session but that's it; (n)vim itself resets it from time to time as long as the file is changed without a edit in vim.

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.

And vim will also reset it while "recover"ing the last unsaved changes. I believe no user relies on it to actually persist the history of a file. If someone is doing that whether in nvim or vim I'd seriously advise you to use a real VCS repo instead.

In practice the feature is as persistent as your last git checkout. There are countless events (including git checkouts, vim recoveries) that simply reset the status of the "persistent" undo. Use a real VCS if you treasure your history as this is just a best effort feature.

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.