[stymaar]

Rust as a language is irrelevant to this discussion, the problem is that bun was vibe coded by a single dude without any open source community involvement. “bun the open source project” is basically dead at that point: don't expect any of the zig enthusiasts who had their code being forcibly rewritten in a language they don't like to follow Jared.

“bun the JavaScript runtime ” is not dead though.

[Matl]

I agree, it's unfortunate the headlines seem to have become 'rewritten in Rust' (not a bad thing) and not 'vibecoded in a week without review' (a bad thing).

[rane]

"Vibecoded" is not an accurate description of what actually happened. LLMs are extremely good at porting code from one language to another while preserving semantics. Which is why how everything turned out so well was not very surprising.

[endospore]

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

Can't help laughing at this point.

[mpyne]

I don't know, did the prior vibe-coded Zig code not ever have pointers aliased to data? Might be preserving semantics too well, if anything.

[endospore]

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.

[pylotlight]

You didn't read the blog post at all did you? Clearly you have zero clue what you are talking about.

[endospore]

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.

[uecker]

Rust as a language is not relevant, but the Rust community still helped to popularize the idea that trashing a community by a rewrite is ok if it serves some "higher goal". This rewrite is just a striking example why this is problematic.

[Dylan16807]

Surely a lot of review has happened in the last two months?

[endospore]

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.

[Tadpole9181]

This feels like such an absurd, bad faith take I keep hearing.

In Zig, every single memory operation is unsafe.

And Bun must interface with C code that has no safe interface, necessitating a ton of boundary-level unsafe behaviors.

There's too much, sure, but can we at least be honest and reasonable?

[ambicapter]

What's the point of rewriting it to Rust if you're going to, on purpose, disable the most prominent benefits of using Rust?

[Tadpole9181]

It isn't disabled, it has exclusions. Now that they have it, they can close the gaps. It was literally impossible to have ANY coverage before, now they are mostly, covered and have an avenue for remediation.

I don't understand why folk are having such a hard time understanding why you do large projects in multiple steps? 80/20 rule? Perfect is the enemy of good?

Was nobody here for moving billions of lines of JavaScript to Typescript? It starts with declarations, then turn on type checking gradually inside the codebase: piece by piece until done.

[skydhash]

I'm not a rust dev. But I've been once asked to take care of a TypeScript codebase and the thing was littered with so many casts to `any`, you're wondering why they bothered with TypeScript in the first place. Some people do choose tech on a vibe and not any real analysis.

[endospore]

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.

[lunar_mycroft]

> Deno for instance have ~0.2x as many unsafes.

Another point of comparison is density of unsafe: the number of unsafe blocks per line of code and/or file. By this metric, Deno has a bit over half the unsafe (because the bun rewrite is significantly more lines of code).

[Tadpole9181]

> I'd remind you the current new version is not an improvement compared to the previous one, both in terms of correctness and maintainability.

Except, you know, multiple real companies saying that it is and using it in production. And the fact it closed all known memory leaks. And that nobody has a really pointed to a single actual issue the new version introduced after two months of endless, ceaseless bitching.

I'm also fascinated by all these people upset at Jarred for harming the readability of a codebase they've literally never cared about before it become drama. Bun has almost exclusively been maintained by Oven employees since it's inception.

> Deno for instance have ~0.2x as many unsafes.

A project written ground-up in Rust idiomatically, with a smaller surface area, still has an unsafe footprint within an order of magnitude compared to this automated rewrite from an unsafe language with different practices and known bugs? That's not exactly the slam you think it is.

[ljm]

> bun was vibe coded by a single dude without any open source community involvement.

I think even this is largely beside the point. The acquisition of any project by Big Capital (whether tech or VC) is usually a killing blow.

[Dylan16807]

Is the idea that a code base reset makes something stop being open source? Or that the number of people doing the reset matters?

I don't see why either of those would be true. The project isn't dead just because it's in a different language now, and for liveness purposes it doesn't matter how it got to that different language.

[avianlyric]

I think the point is that an “open source project” is more than just the code and license, it’s also the community that builds and maintains it.

A fast rewrite of Bun in Rust has effectively alienated most of the people in the Bun community, so in that sense the “open source project” has died. It’s no longer a community project, it’s just become a personal project again.

[Tadpole9181]

Just so everyone know, Bun is and has always been owned by a YC funded org with full time employees. The overwhelming majority of commits came from them.

[Dylan16807]

A reset is very different from not being open source any more. If losing most of the community would mark a project dead in open source terms, then every new project would be dead on arrival. And that would just be silly.

[CrimsonRain]

That's just like your opinion...? More power to Jared (and anyone else) if they can "vibe code" useful projects like bun.