Bun 1.4 Rust rewrite is not looking good
99 points by robinheghan
99 points by robinheghan
Looking at the clanker pull requests for Bun, e.g. this one, number 39590 (!), I cannot help but get a deeply dystopian feeling.
If the internet is not dead, at least collaborative programming is for a significant part: It's just machines talking to machines. And the code is so messy, which human would be willing and able to even read it? Or is the result going to be so messy that one requires the assistance of a machine to even traverse it?
The big AI companies are hooking people on the agentic programming part, but they are like drug dealers, making people dependent on their services (and forcing monthly subscription costs) to even be able to understand the masses of code spat out by those tools. The more dependent we are as a society, the more they can dictate the prices.
I don't think the dust has settled yet. One of the things I've only appreciated about OSS since AI took off is that it also serves as a global coordination mechanism. I don't just use Postgres because it does the thing, I also use it because I know it does the thing for thousands of different people with very different problems to me. Over decades, those thousands have slowly trickled their solutions into this abstraction that has become extremely well defined and battle tested.
I can't image single-user AI software having the same aura. Maybe one day it gets so good we don't even need to general abstraction, because AI is the even more general layer underneath that can write it, but it seems we are a long way off that.
Is it not most, if not all, software that serves as a global coordination system? I suppose I'm invoking Naur's, "Programming as Theory Building" here. Even if I am the only one that wrote and uses a piece of software, when I revisit that code years later I want to know the basic facts of whether it ever fulfilled its intended purpose and indeed how successful it was. I feel like that's exactly the same relationship I have towards projects like Postgres. I don't necessarily mind if software doesn't perfectly fit my needs, if there is evidence that the code has been used in similar ways, is amenable to customisation and has a community or documentation to support it, then I'm willing to invest time.
It makes me wonder whether Computer Science is the wrong subject for software engineers to study. Of course traditional mechanical engineering fundamentally relies on its purely scientific counterparts, but ultimately it is of a categorically different nature. The applied sciences are steeped in the almost Scythian task of constantly implicating reality. Which is a challenge that every engineer must journey and mature through themselves. In other words, how does one not only create a "global coordination system", but how do we sustain and nurture it? Reality is not a problem that can be solved. It is ever changing. Yet a good engineer, through both intelligence and diligence, can create systems and processes that are resilient and adaptable to the mercurial reality of nature and the humans that live in it.
As such AI is not, and I suggest never will be, an engineer. AI does not apply itself to reality during inference. That's not to say it's useless, it can regurgitate the status quo of Computer Science. It's the old adage: 2 mothers can't grow a baby twice as fast. Computers, like life, are just hard. There are certainly things that can help, but we mustn't let that fool us into believing we can be taken out of the loop. In fact I would say that the desire to be taken out of the loop is never about efficiency but always just good ol' existential angst.
I don't just use Postgres because it does the thing, I also use it because I know it does the thing for thousands of different people with very different problems to me.
This is often precisely what ruins a particular software for me, forcing me to move on to a more minimalist software that has a well thought out feature set without all the bloat and feature churn.
Intelligence isn't the same as abstraction. Intelligence isn't the same as infrastructure. You can't say "I'm a smart person, so I do not and will not need tools." The smart person is the person who uses the right tools, and builds on top of the right abstractions
The code has to be a hot mess to sell you on the idea that you won't want to read code, and that in fact nobody ever will again.
If LLMs, just wrote good code, logically it would be useful to look at
I'm tired of seeing this claim for rust rewrites:
The number of unsafe blocks in the Rust code suggests the rewrite did not deliver the memory safety that was given as the reason for doing the rewrite in the first place.
This project replaced an implicit "unsafe" attached to every block of zig code with a few explicit ones that are still being removed. This includes explicit ones which cannot be removed (extern C) On the first 5 pages of GitHub search for that keyword, I found only 1 case that seems questionable. And some that could be probably removed with a change of architecture. But this quote from the post is not supported in any way. Bun never claimed to go purely safe Rust with no C dependencies and any removal of unsafe blocks is their progress in the right direction wrt. memory safety.
Some background, with no other judgement (I have not followed it closely and have no interest in investigating):
When they first shared the Rust port, there was a lot of unsafe, and people quickly found multiple flagrantly-wrong unsafe blocks. This was defended as temporary, for the port was by no means complete: that they would be rendered obsolete or repaired in short order.
They were heading in the right direction previously, so I checked on th VMe counts and for some reason the number went back up. I thought they'll continue the cleanup over time but no - https://photos.app.goo.gl/TLjkscAL2QgKwDYw8 (I'm away from the desktop, so this LLM generated) we're back at close to the highest count. I wonder what's the reason.
I agree with the sentiment of your post as well. I think that unsafe blocks are a good indication of potential sources of issues and I'll want to refactor them out. A clear signal of "oh no I should try to fix this".
Generally my usage of Bun ended up being "Bun isn't working out for me" rather than anything proglang usage related.
This project replaced an implicit "unsafe" attached to every block of zig code
Kind of an unfair framing of Zig imo. Zig isn't some wild west of memory footguns, and while "just trust me" with memory safety is something I don't think is a good solution (at all), it is safer than C. Not the greatest bar to clear, but it does mean they could use their infinite amount of tokens to add rigor.
Bringing it back to the article, maybe they did to that, I will never know because when I browse the repo/project it's like some uncanny valley type of OSS project and I don't think that looks good.
Kind of an unfair framing of Zig imo.
It wasn't a judgement of the language. I meant it literally. You can write to a @ptrFromInt(0x1234) whatever you want, without any explicit attributes on the function. Which means that compared to Rust's unsafe keyword, all of Zig and C would be enclosed in an unsafe block. (Not that we should expect adversarial code in either)
You can also write an unsafe block in rust without any explicit attributes on the function. @ptrFromInt is just as grep-able as unsafe is.
I'm pretty all they're saying is something like: the memory safety of all Zig code is as unproven as unsafe Rust code.
Not a dig at Zig necessarily, simply saying that a function ported to Rust using unsafe hasn't lost anything, whereas a function ported to Rust without unsafe has gained something.
To be fair, Zig has more sources of unsafety than just @ptrFromInt. Just grepping for that won't do.
To be even fairer, even Rust has sources of unsafety that don't involve the unsafe keyword. Those are mostly things that don't happen inside functions but may cause the program to do UB anyway, such as global_asm! or linker attributes. There is also the opposite, syntactic positions of the unsafe keyword that don't actually indicate any possibility of UB, such as declaring an unsafe trait.
Therefore, I think grep (or regex in general) is too blunt a tool, at least at scale. And in the context of 1MLoC+ projects like Bun, we're at a scale where even relatively rare false positives can become quite noisy.
In Rust, there is a - slightly more complex than regex but still reasonably fast and simple - way to check for all unsafe language features, it's the unsafe_code lint, which also correctly flags linker attributes and such. You can use cargo-geiger to recursively check all your dependencies for this as well. I wonder: is there something like that I can use for Zig?
even Rust has sources of unsafety that don't involve the
unsafekeyword
That's a misleading framing. There's still a finite small amount of unsafe Rust constructs you can easily grep for (and Rust 2024 made the set smaller by finally adding unsafe to linker attributes). This is still very different from C/C++/Zig that don't have guaranteed-UB-free sections of code.
I didn't mean to mislead, I think we're actually in full agreement here. There is a simple and correct way to scan Rust for unsafe constructs that is barely harder than grep unsafe, and it's what cargo geiger does.
I don't know too much about Zig, so I'm asking: Is there anything like that for Zig?
I see, I'd expect a lot of cases to be catched by tooling around the codebase(tests/build flags/fuzzying/sanitizers), but I wonder how unsafe their usage of Zig was that they thought more compiler driven system would be worth the rewrite.
This post doesn't contain useful information. I understand why it is on top of lobste.rs, but I don't like this fact. I wish we used our collective voting power better to help each other find signal in the noise.
This post sounds like it answers two extremely interesting technical questions:
The article contains no data points related to these two questions. It actively avoids making a technical contribution, in favor of looking at the meta points and signalling mood affiliation.
With meta points, the article fails to mention the critical detail --- that the Rust version of bun is what powers Claude Code these days. If the author knew that, and omitted from the post, that is disingenuous. If the author didn't know that fact, they are probably not qualified to write about this. There's also a chance that I am actually misinformed here, and Claude Code still runs the Zig version, but this is a popular enough claim that is must be investigated in this sort of post.
What I want to read is an article discussing bugs introduced, fixed, and avoided by the rewrite. It's easy to do if there are bugs, it needs to be creative if we didn't observe the bugs. But this article is not it, not it at all.
I want to read experiencies of people looking at the code, running the thing, and hitting the bugs. I don't want to read armchair analysis of release schedules, especially if it doesn't contain in-class comparisons (how long did it take Microsoft to ship Go version of TypeScirpt compiler?)
I want to especially highlight this passage, which I think is a emblematic of the issues I have with the article, and with its reception on lobsters:
I thought he was a true Zig talent, until I read Zig creator Andrew Kelley’s thoughts on the Bun rewrite
This is bad thinking. Sure, a lot of "trust the experts" is required in our world, but we are the experts in this particular domain. We can just go and look and see for ourselves! "Andrew thinks Bun's code is not good" is an empty statement, and argument from authority. "Bun only started fuzzing code after being acquired, shortly before or concurrently with the rewrite" is a factual statement that carries weight.
All that being said, I don't actually have any problems with the post per se. I would prefer to not read it, but I imagine for someone running Bun 1.3 in production it can be quite useful, and the world is a better place with this post existing. I only have the problem with lobste.rs treating this post as "LLMs vs Rust vs Zig" battle royale, while it actually adds more smoke than light in that interesting domain.
(I used to write a tonne of Rust, I use Zig for work, I don't use AI for coding, my blog runs on Deno, and I don't know a person who is better at making technical decisions than adrewrk)
Can LLMs rewrite large codebases from language A to language B, without reducing quality bar?
Perhaps an interesting follow-up question in the context of Bun this might be: If LLMs can rewrite large codebases from language A to B, why would anyone write or run any Javascript in the near future?
If LLMs can rewrite large codebases from language A to B, why would anyone write or run any Javascript in the near future?
I can answer you that question! We maintain a project that is TypeScript and plenty of people have been asking us if we can rewrite it in Rust. However we also require dynamic loadable code, and some of our users are needing to deploy this to Cloudflare, where anything other than JavaScript does not really work (at least not without becoming pointless).
There are still tradeoffs. More importantly one could get the idea that the fundamental issues of languages are gone just because agents are now writing them. From experimentation I can tell you that building an application in TypeScript with an agent is still a much more dynamic and iterative experience than doing the same with Rust.
Do you have any insights as to why Anthropic wouldn't rewrite Claude Code in Rust? It doesn't seem very logical to me to acquire Bun and rewrite Bun in Rust. I switched away from Claude Code in favor of Codex over half a year ago and never looked back, and I enjoy how fast Codex is relative to Claude Code (Codex is written in Rust).
The rewrite to Rust wasn’t an Anthropic decision, that was Jarred. As to why Claude Code wouldn’t be rewritten in Rust I don’t have a lot of insights but I am not sure what the benefit for Anthropic would be.
Don’t forget that Claude Code also runs on the Claude code SDK which is TypeScript and peopled build against. Additionally Claude Code is also embedded in Claude Cowork which is an Electron app.
It sounds like a risky undertaking and what would the benefit be?
It sounds like a risky undertaking and what would the benefit be?
Well, if the thesis were that LLMs are any good at software engineering, then it would seem as though it would be natural and not at all risky to make a product that is responsive and efficient in resource utilization, which presumably would attract more users, as opposed to building a product that is slow and inefficient, which I would assume to have the opposite effect.
But it's also a philosophical question — do companies want to build a good product or do they want to make money? If the goal is to ship mediocre software at low cost, firing all the expensive engineers, then everything checks out, and LLMs do not have to be "good."
Well I already explained you that there are reasons for why TypeScript is probably a good language for Anthropic. I know that for our use case, which is quite related, TypeScript is a good language. I already have the agent build a Rust version of what we are working on more than once, and the tradeoffs don't seem right. Despite all the shit that people give JavaScript, it's a remarkable good system when it comes to async across platforms.
I honestly don't think you actually really would care either way what Anthropic does, because your general sentiment is quite hostile towards LLM generated code. I am sure if Anthropic were to rewrite Claude Code in Rust, it would not change your opinion about the thing we're discussing in any way.
It appears to me that your real point is that TypeScript is a convenient programming language for Anthropic, and not that TypeScript is better equipped to facilitate building a good product. Not to mention that Claude Cowork is a relatively new product from Anthropic, so why choose Electron when it is so notorious for being slow? Is all this really just to make sure they follow the DRY pattern?
My sentiment is not at all hostile towards LLMs or LLM-generated code in general. If anything, I am very much "pro-LLM," however, AI labs ought to be clear about the limitations thereof, instead of making dishonest claims in order to raise capital.
I think you just want to make different choices than Anthropic. Which is fine, but I don't know if your choices would be objectively better?
I happen think their choices are quite rational because they align with mine. TypeScript has become the standard choice for me to write application code in these days because it lends itself quite well to different environments. And I say this as a huge Rust proponent that introduced Rust at both the company I worked at for ten years, have built Open Source software in Rust and advocated for it for years.
As a former Tauri user I also moved to Electron because it's just the more stable and enjoyable environment. For the complexity of stuff I build, I feel quite at home there. Is there something else out there? Maybe. But Electron is a very fine choice.
I don't know what it is that you are building, and it sure could be that you are ahead of me on the curve, but it's not immediately obvious to me which environment TypeScript would lend itself better to than Rust would, other than Cloudflare Workers, which actually does support Rust, so if your concern is just the ability to share code, I believe Rust would still work fine, even though you mentioned that it "[becomes] pointless" for some reason.
Tauri is not really what I had in mind. Have you had the chance to check out Zed's UI framework GPUI? I have not, but I was really impressed when I opened Zed for the first time and I really enjoy using it. It's like going from a 60hz monitor to a 144hz one.
but it's not immediately obvious to me which environment TypeScript would lend itself better to than Rust would
In our case it's building self modifyable software and a system that supports that. Rust is a rather poor choice there because it neither has a stable ABI nor does it have reflection in the core which makes it a poor choice to expose system types to a dynamic language for embedding.
The original claim from Anthropic was that React/TS was "on-distribution". But that seems like a strange thing to index heavily on. I would bet real money that the median Rust code is more correct and written to higher standards than the median TypeScript code. (I'm not a fan of the first cut of Rust either Claude or GPT Sol write, but that's because I care about putting invariants in the type system more than most people.)
I don't follow, are you saying that all Javascript is inherently bad, or that LLMs will eventually transpile any language to JS?
For what it's worth Claude Code has been running on 1.4 for a while and quite a few people in the ecosystem are already using the Canary. Whatever the reason is not for shipping a stable release has not stopped people from using the canary.
I don't find that particularly interesting. What bun-specific APIs does claude code need outside of the js runtime itself? Reading/writing files? Spawning sub-processes?
A JS runtime for CC is such a narrow use case. Further, claiming that "bun is being used in claude code" is a signal that the project is over-fitting to a specific use case. Can't we argue that this is actually a problem for a project that was originally designed to be a node replacement? I understand that the project is early in its transition to anthropic/rust but all I see are red flags.
Why does it matter if Claude Code uses Bun specific APIs? I don’t know how to answer that question but I also don’t think it’s relevant?
I understand that the project is early in its transition to anthropic/rust but all I see are red flags.
What red flags do you see? I don’t see anyone complaining about Claude Code with regards to the Bun build.
I’m really not quite sure why some people are so emotional about Bun. It seems to work decently well in 1.3 and 1.4.
Why does it matter if Claude Code uses Bun specific APIs? I don’t know how to answer that question but I also don’t think it’s relevant?
Because the JS runtime wasn't converted to rust, it was the Bun scaffolding that changed. If CC doesn't need much of the Bun API then why would there be any issues with the migration? You're in a thread discussing the zig->rust conversion. What am I missing?
My impression was that you asked about bun specific APIs. All APIs that Claude calls are in that sense Bun APIs. When it sleeps, opens a file, spawns a process, invokes a web worker, parses JSON, asks for the current time etc. it invokes Bun code that was Zig before and Rust now. Very little of then API surface comes from JavaScriptCore same as with node and v8.
Lots of the JavaScript standard library is covered by JavaScriptCore. I don't think Bun has to do anything for APIs like parseFloat and JSON.stringify and Number#toString and the like.
Lots of the JavaScript standard library is covered by JavaScriptCore
The "lots" does a lot of heavy lifting here. The globals are provided by JavaScriptCore and that's pretty much it. IO, file system, sockets, HTTP, all async functionality, scheduling, workers and pretty much anything related to interacting with the operating system is from Bun. Bun also maintains an active fork of WebKit so there might even be changes to some of the globals, though not sure how invasive it is.
I have found LLMs to be good at vibe porting code, especially with a decent test suite. The original source code offers clear direction, so it's harder to get things wrong, and fixing a bug likely means reviewing the code for oversights. Porting libraries between languages suddenly became a lot easier, which is fascinating.
You do have to watch it - once, porting Fortran to Rust, I found out that rather than calling the original Fortran code to generate test data, it had hit a roadblock in linking that, so it just generated NEW Fortan code to generate that data itself.
But I did this on non mission critical projects of small to medium size, and I didn't let the LLM just go off on its own either. Zig is also one of the less established languages out there, and it sounds like there is a lot of trickery in Bun that blocks blind porting to safe Rust and may require architectural changes.
So perhaps the ease of vibe porting stuff in general misled the Bun devs to be overly ambitious. LLMs can make humans overly ambitious. And of course this porting effort may still end up successful given more time. But concern when a core piece of a platform changes out from under you in a rather wild experiment is totally legitimate.
Agreed on all points.
A further implication: we (software engineers) have spent decades figuring out how to use the tools we have (and building new ones on top of those) while these new LLM-based tools are of an entirely different character. It will take quite some time for us to adjust our practices to use them well.
(Oh hey, I realized I know you! hello!)
Agreed! This is the biggest shift in software development in my lifetime by far, and I experienced 8 bit computers and the rise of the internet. The psychological adjustment is absolutely enormous and there are a lot of weird pitfalls. We live in strange times, and we have a lot more learning to do.
This is the biggest shift in software development in my lifetime by far, and I experienced 8 bit computers and the rise of the internet.
One of the differences for me is that this is the first big shift that doesn't have a historical precedent in computing.
There were other major shifts, but most of the ones that come to mind (garbage collection, REPLs, reusable data structures) already existed—they just hadn't trickled down to the DOS computer I grew up on, so they didn't exist for me. Cue all the jokes about Lisp being alien technology from the future, etc. The commercial Internet and the proliferation of reusable libraries were a little more novel, but still recognizable as extensions of the preexisting.
Not that LLMs didn't grow out of previous research—just that they're much more unrecognizable compared to their ancestors. ELIZA was not writing code for researchers back in the day.
Yes, that's a cool insight! Those other shifts were about the future not being evenly distributed.
And nobody was using LLMs for code until relatively recently. If you look at LLMs through the lens of reuse, we basically got a whole new class of reuse: we had reuse by copy & paste and reuse by abstraction, but this is like both, and neither.
The reason this particular future could arrive more or less instantly is because of the digital nature of it - both the availability of training data and the usage of models depends on the internet already having been cooking for a bunch of decades.
And the other reason it arrives so quickly is because it's applicable everywhere we have code. It's not language dependent, or project dependent. You don't need to do a lot of engineering to start using it. In that sense it's more like an editor, and we have seen rather fast shifts in the last 10 years with those.
once, porting Fortran to Rust, I found out that rather than calling the original Fortran code to generate test data, it had hit a roadblock in linking that, so it just generated NEW Fortan code to generate that data itself.
Current LLMs do seem to have taken “you can just do things” worryingly far.
I've used it to port F# to Lua too.
(The Fortran stuff was scientific climate change models mad science experimentation, the Lua code I actually run - the vscode rewrap extension has its core written in F# and I wanted to use it in the micro editor which uses Lua plugins. and then I just did things)
[edit: rereading I figure you actually meant the LLMs just work around using weird assumptions, which they do. I heard it expressed as it causing 'epicycles']
I have seen efforts to rewrite a large complex system and effort to convert code from one language to another. They have, without exception, taken far more time and effort than expected before they were in a condition. I would consider ready for production.
Because of that, if I were doing a conversion like this would not announce it until it was ready (or extremely close to ready) for production quality release.
So, when Jarred first posted about the conversion in a tone that suggested it was almost ready for production release, I assumed they were doing me the same as I would have. And yes, I was extremely impressed that AI was able to perform such a translation.
As this article makes clear, it was not and probably still is not close to "ready for production". I am not sure that I have learned any meaningful lessons about the capability of agentic AI to manage entire software projects. But I have definitely learned that Jarred turns out not to have the same level of professionalism (at least in his communications) as what I strive to me maintain.
As this article makes clear, it was not and probably still is not close to "ready for production".
To be fair, the article does not make that clear. The new version of Bun has been shipped with Claude for a while now in production and it's doing fine. The delay seems to at least partially come from massive scope creep - the twitter posts advertise interesting architecture improvements that could wait until after the first release.
Constant scope creep with new features and architecture changes is a good way to keep a piece of software from becoming production ready. If that's really what's going on here then that's absolutely terrible project management; especially for something as high profile as this Rust rewrite where a significant part of the rationale is to advertise Claude's capabilities. Hitting timeline targets would've been much more impressive than constant missed self-imposed deadlines.
AI has the property of accelerating a whole lot of things not just typing out code or happy path feature delivery. It also accelerates:
It never removed the need for discipline and if you didn't have discipline before then AI isn't going to magically give it to you. What it will do is help you hit that quality wall way faster than you could before.
So, IME, documentation rot is something that, at least in my project, Claude actually was very careful to guard against, and was diligent about re-writing it's own internal documents to match the code, and as well, to update other documents and even to write tests to make sure that documents matched the code.
OTOH, the pressure for scope creep is insane, claude would keep suggesting "improvements" and you would find yourself thinking "Oh, yeah I should do that" while forgetting that you had a specific set of requirements.
My project is brand new, so we'll see what the defect rate is like...
This is only one POV, on a small toy project, but I was actually quite impressed with the diligence for keeping proper documents.
In every Claude-heavy project I've seen, documentation has been terrible. Not because it's missing or necessarily wrong but just because Claude generates sooooo much of it. Page upon page upon page of the most verbose drivel you've ever read. LLMs are terrible writers and even worse technical writers.
so we end up with a documentation which, I assume, is mostly technically correct, but which is entirely useless because nobody will ever read it. But the people responsible for the garbage believe they're doing a good job because they "have documentation" now.
Page upon page upon page of the most verbose drivel you've ever read.
Absolutely. In addition to seemingly being paid by the word, it has a bad habit of constantly referring to the prompt or a spurious situation that happened while testing the code.
Tons of code comments like "Add x to the database and recover in case of error. These errors are unrelated to the formatter error that happened because an older version of the formatter was installed on the system."
However, it's pretty good at spotting errors in existing documentation.
I think the way people use this is going to change the calculus a lot. I've seen projects where claude is setup to keep it in sync and projects where that is very much not the case. I've seen it the worst when more than one person is using claude on the project.
The delay seems to at least partially come from massive scope creep
Yes maybe, but maybe people also just need to chill. For instance zig 0.16 also took half a year to release and there were plenty of zig releases that took longer than that.
They have, without exception, taken far more time and effort than expected before they were in a condition. I would consider ready for production.
The fish shell conversion seemed to go quite well. I did not follow it too closely though.
They have, without exception, taken far more time and effort than expected before they were in a condition. I would consider ready for production.
The Typescript compiler port from Typescript to Go seems to have gone remarkably smoothly.
It’s now three months and counting since the last stable release, the longest gap in Bun’s history since 2022.
Claude prompting Claude
This looks like classic "we don't understand where the project is" slippage.
My experience is every commit I don't make erodes my mental model. How do you maintain a mental model of a system with mostly invisible state when something else is doing the work?
It would absolutely not surprise me if Jarred (the main force behind bun) is completely burnt out from the backlash after the rust rewrite. give the guy a break.
Blame AI if you want because that suits the popular narrative here. But if the zig author wrote a blog post and said the same things about code I'd wrote I wouldn't feel particularly inspired to working on software...
give the guy a break.
I hope he can just take a break in case he wants to. If my project had been acquired by Anthropic for a billion freaking dollars, I'd probably just retire instead of burning myself out.
Edit: typo
These deals are usually structured in such a way that an immediate exit of key personnel is unlikely.
I am not aware of any pricing details having been released. Given that the project had raised $26 million, I doubt it was valued at a billion dollars (freaking or otherwise).
You’re right. Anthropic reached a $1 billion run-rate revenue with Claude Code at the time it acquired Bun. Still, estimates range from $100 million to $200 million, which should be enough payout for the previous owner to retire if they want to, at least I hope so.
We don’t know how much of that amount was paid in Anthropic stock rather than cash. A significant percentage could be tied up in pre-IPO equity.
give the guy a break.
You know, he is not doing us any favor?
Who is "us" and what is he doing?
at least me, the guy you asked to give someone a break and everybody else that agrees this is a marketing stunt (and not a good one as it seems the maintainer can't release what they promise even after 4 months).
everybody else that agrees this is a marketing stunt
Presumably I’m part of “everybody else” and as someone who hung out with Jarred to chat with him about all of this for an extended period of time I did not walk away with the feeling that it was a marketing stunt.
and not a good one as it seems the maintainer can't release what they promise even after 4 months
Python’s release schedule is measured in almost years. Should we feel bad about Python because of that? Python 3 took years to release and a decade to stabilize. Some things just take time. I don’t quite understand people’s urgency.
Folk are reacting to the promises from LLM companies about work like this being "solved". As this is now an Anthropic project, people are expecting, or at least petulantly demanding, that this live up to those promises.
I doubt the majority of the commentariat care about bun in the slightest. I don't, but I do care about the promises Anthropic makes about this workflow and whether it can deliver on them.
I think Jarred is caught in the middle, but he also presumably took a lot of money to become a member of Anthropic, so it's complicated.
Some things just take time
I don't think Bun would have better feedback if they released it earlier, a large subsection will just say "see they are shipping fast and not caring for breaking changes!".
I don't think Bun would have better feedback if they released it earlier
There are canary releases since basically day one. I'm sure they get plenty feedback, particularly from the folks at Anthropic using it.
I'll never know because that repo way too complex for me to follow along.
I use a lot of programming languages and runtime environments and I basically never "follow along". And yet, I can judge the quality of what I'm using and how it's changing just fine.
How many vibe-coded/LLM run langs/runtimes do you follow?
I didn't mean to imply that somebody should have some sort of more indepth relationship with the repo(the breath of a runtime is crazy!), but the changes of such projects sustained over time were always easy to follow for me. Node breaking changes, new JS features, proposals, review discussions, tradeoffs made in PRs for certain features; weird packaging issues with a fix that isn't out in a release just yet, browse through the log. I just can't imagine that same way with a project where the communication is being done like its currently being done.
The first thing I feel when browsing through Bun's repo is that I'd need another bot to just filter through their bot noise.
How many vibe-coded/LLM run langs/runtimes do you follow?
I am not sure that matters? I use a thing, I don't really care how it's being built.
The first thing I feel when browsing through Bun's repo is that I'd need another bot to just filter through their bot noise.
Sure, but … why does it matter? I mean, maybe it does, but it probably matters more for the people that build it than the people that use it. I don't wake up in the morning and fill my day by reviewing the repos of the tools or libraries I'm using. Only when something fails, do I go there. I did contribute to Bun (during Zig times) a fix, and I found it hilarious (and uncomfortable!) to interact with Robobun. But I guess if I were more regular contributor I would change my behavior as a result of how that project works? But again, beyond that interaction I had with it, I really do not care how Jarred or Anthropic run their project.
I am not sure that matters? I use a thing, I don't really care how it's being built.
I'd say in the context of "figuring out if feedback is being received", that matters...well to me at least. I can imagine that somebody could not care about how it's being built, but hopefully you can also imagine that people would care about that?
Bun can be doing very well for a lot of people, but I already used Bun a lot during 0.7 and 1.0 times and outside of basic SPA stuff I could never really get it working in a predictable/stable way. Maybe the long canary is here because those type of things can get avoided, I just can't figure it out from the repo, except for: "Anthropic uses it". And I feel like comparing that repo to other platforms/runtimes is one I just wouldn't make because it's so different than I'm used to.
I think the rate/impact of changes of a platform matters also if I want to assess it/try and use it for (new) projects. If it's frequent and big changes, sustained over time, then why am I building on a platform that might be hard to predict maintenance wise? Will it be worth the technical trade-offs?
I don't wake up in the morning and fill my day by reviewing the repos of the tools or libraries I'm using.
I don't do that either, I don't think this was close to what I was saying?
"In the next version of Bun" used to be a positive tweet to watch for. For years it meant a feature had been implemented, tested, and would ship in a few days. This changed after the Rust rewrite. Now the posts are false promises about the upcoming release:
This also happened with Bun 1.3, the lead is just bad at release timelines (iirc at a few recent points he joked about this as well).
I hope they release a cost analysis. I'm genuinely curious. In particular, I'm curious if the "LLMs are cheaper" argument holds when compared against non-US tech salaries, as that's relevant to me personally.
I wish people writing posts like this would be more concrete about what they're claiming. Is it:
I'm in the fourth camp but I wouldn't describe that as "not looking good" as opposed to "being poorly managed". (More concretely: I expect the rewrite will be released by end-of-year and will work at least as well as 1.3. End-of-year is of course an absurd delay, it should have been released by now and should be released soon, but I have no confidence in Jarred's ability to keep a timeline.) If you disagree, care to make an actual prediction?
As far as I can tell from following Bun's github, it's just that they keep adding more features and minor bug fixes and node compat and performance tweaks/improvements instead of cutting a new release. I wish they wouldn't do this, I do think it's a sign of bad project management, but I'm not sure why we're supposed to infer it's "not looking good" or even what "not looking good" is supposed to mean.
I think the rewrite will end up being more expensive (for the same quality) because AI was used.
At the same time this specific rewrite is being used to drive the narrative that reading the code is counterproductive.
If they had delivered their promises, they might have convincingly delivered that argument.
...but the cost keeps going up and up and up and up and up and up and up and up and up and up... So I now find the argument that AI use was key to making this possible holds significantly less water. If it was only the token costs it might still be economically viable, but I'm imagining that when you add in the pro-rated salaries of the human engineers this would start to look like a financial blunder even if it released today.
Jarred's salary is effectively huge. That goes in both the human-rewrite and ai-rewrite columns, so at first glance it's a wash.
The main thing I would point to is that what makes top people so valuable is their ability to make other people more efficient, effective, and valuable overall. In the AI scenario I would file that under opportunity cost, because it isn't happening. Technical and human capital aren't really being built over time, and models do not learn.
I think this is an interesting point! In labour market terms, LLMs are making individual professionals way more productive (or less productive, depending on how they use it), but it doesn't help managers to manage people. Hence their focus on attempting to replace people instead. If the market was truly rational, perhaps it would even be a boon for labour, a new source of leverage over the bosses. The capital cost of the technology counteracts that though :(
In another thread here some days ago the Bun rewrite was used as an example of something that AI has to “show off”. Well it does not seem it is after all.
I remember when Bun first landed, and I was pretty excited about it all. Finally some fresh ideas in the JS space that might just improve it overall, I naively thought. I was very engaged with Bun, trying to help people use it, opening issues and such. One of the first issues I opened is still sitting there today.
I frankly had been slightly distrusting of Jarred since finding out he's a Thiel Fellowship guy, but this is a whole new level. Feels like much of what I love(d) about programming is being eroded by these AI companies. I just hope it ends sooner than later.
Wasn't Bun only fun because of Zig?
I'm not really a Bun nor a Zig user, but from my outsider perspective that wasn't the main draw. To me, Bun was mainly about performance and feature-completeness. That is, it comes with a lot of batteries included and you can build something useful with few or no extra dependencies that also outperforms the same thing built in node.