ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
57% Positive
Analyzed from 4826 words in the discussion.
Trending Topics
#code#rewrite#bun#rust#claude#more#llm#software#release#those
Discussion (146 Comments)Read Original on HackerNews
Jared and the other developers are new to the Rust codebase, even if the structure is largely familiar. They're also likely focusing on other priorities right now such as tracking down instances of 'unsafe', rather than making user-facing changes (which might encourage a release).
Bugfixes could encourage rapid new releases, but perhaps the rewrite simply hasn't been very buggy? As far as I know, those on the canary channel haven't reported any major issues, or even really noticed the change. So perhaps there's little reason for new releases right now, as the team slowly churns through the backlog.
> P.S. Anthropic’s C compiler and Cursor’s FastRender web browser haven’t had any commits for months.
I always assumed those were just experiments in capability, and weren't meant to be ongoing projects. I would hope that nobody is using them directly today.
I think they're taking things "gradually" as they are under a lot of scrutiny and no rush for full release.
This is an impressive milestone for their rewrite. There are a lot of comments trying to downplay this as being unimpressive for some reason, but I can’t see them as anything other than sour grapes because the rewrite hasn’t crashed and burned like they were hoping.
But at some point if “moving one of the biggest actively maintained and used codebases to it without anyone noticing” is dismissed as “it doesn’t mean all that much”, then we’ve lost the plot a little bit somewhere.
Claude code interacts with many system processes, files, etc, as well as external APIs. Processes audio via built in dictation. Manages a bunch of nasty auth. Etc etc.
What are the categories of features that wouldn't be exercised by this class of software?
To release this to the world and not have it be a catastrophe, they need to have confidence that Bun itself satisfies the promises that it has made, both explicitly and implicitly (bearing in mind Hyrum's law!) to all those projects out there using it, none of which are owned by Anthropic and many of which are not source visible to them. It's a much, much higher bar.
But what makes software is not the fast creation of a "product" but that actual development of its features. Figuring out how everything needs to work together, fixing the bugs, and the o so boring UI work.
I have used LLMs to create stuff like word clones just for fun. It was a disaster. Sure, it had the basic functionality. But the moment you started with page structure (harder then one non-stop scrolling page), tables, images, rotating, and so many details that make up just the basics of word. Not even the extended functionality. You see every LLM just fall on its face.
Sure, i can clone sqlite from c to rust. Hell, i may even get it to do all the tests 100%. But there is a 99% chance that the clone will be slower, as it lacks the years of optimizations from the original language. There will be new bugs because of the language changeover. There is a need for future support and fixes.
People threat software like its something it is not. But unlike the past where your clients question your sanity for charging 100k for a piece of software. Not understanding its not just about writing the code. Now those expectation are even more pushed forwards, because of articles like this.
I constantly see software being published on reddit that does X, Y, Z only for the authors to abandon it as fast as they vibe coded it. Because fixing bugs is NOT sexy. Even with a LLM at your fingertips. Dealing with nagging users, is not sexy. Dealing with security issues, is NOT sexy. Dealing with data structure / databases, especially as your system changes ... you get the point.
Not understanding to the core the software you wrote, is going to exploded in your face.
This is why these stupid "we rewrote X into Z with a LLM in Y days" mean nothing. Its one thing to get a head start using this trick, its another to actually learn the code of your rewrite. And dedicated the time into maintaining the port, growing it, fixing it. This is where a lot of software fails. But now this crap is out there, instead of the maintained version of Zig, now we have a unmaintained Rust version that clouded the airwaves because if people now search for it, those articles "X in Z days" will pop up.
What have we become ...
If you explore Github, you're gonna see thousands of abandoned game engines, compilers for made-up languages. And that has been happening since before the LLM era.
I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS. A dozen people or so could even run Firefox! I remember (now legend) Terry bothering us to check out LoseThos or GodOS or whatever was its name, but quite a few people had OSs that could do more than that.
Not all software needs to be commercial to be useful, even if it's just for a learning experience. I have learned a lot from those experiments, even if they're not polished.
Yeah, but the people authoring those learned something.
> I used to be part of an OS messaging board in the early 2000s and almost everyone had their own OS.
Great example! I, too, once had my own toy OS, and browsed OSDev wiki nonstop. The thing is no one in the OS dev community were writing things they intended to place in front of actual users!
The difference now is that these incomplete projects:
a) Don't leave their owners any wiser than when they started, and
b) Are actually intended by their owners to be used by actual users.
> I have learned a lot from those experiments, even if they're not polished.
Would you have learned as much if you told a magic box "Make me an OS" and then slapped your name on it and uploaded it to GH?
Temple OS :)
This is fine so long as the author is learning something (questionable) and not polluting the commons with "I made this in a weekend" vibe slop.
But it seems like we're finally starting to accept that "accidentals" like network effects, ownership, accountability, etc. are important. Of course, that's why many of us fled to technical corners in the first place - because the "accidentals" become tied up with things like nepotism, unfair and arbitrary judges from random humans who don't understand your merit, the need for bullshitting more than real technical value. Supposedly, anyways.
I never thought of this from this perspective but indeed it seems to be totally true.
I worked for a startup that stopped feature development and did a complete rewrite of a huge codebase. I was assigned to a side project during this time and missed the entire rewrite process. I came back to a completely rewritten codebase.
There was almost no learning curve, despite being in an entirely different language. The core architecture, data structures, and concepts were the same.
If you read the Bun blog post on how they did it, their rewrite was similar: The first step was getting it into a new language, not rearchitecting it from scratch.
I think they did it the right way based on my pre-LLM. Rewriting into a different language as fast and basically as possible is important for getting the team switched over quickly. Rewriting into a different language in X days is actually a good goal to minimize.
Also if you whip something up, you tend not to care for it as much as something you took the time to create in a "proper" manner.
What do you think of https://scramblequest.app and https://wordpeek.app ?
I have never looked at any of the code for them
edit: Yeesh, misread your comment as "word games" not "word clones" and was very confused about the claim. Probably should have noted my confusion and re-read.
Word is basically an operating system. Unix people like to make fun of Emacs for being one, but Word is basically one, too. And all the features in there are used, otherwise Microsoft wouldn't keep them around.
And .doc files are basically a memory dump.
In case of ccc (claudes C compiler) they just did not use any tests, though they are many existing C testsuite. They just stopped, when it finished compiling the kernel, still failing hundreds of tests.
Not really. Transpilers have existed since forever.
The hard part is all the edge cases. (And LLMs don't solve this problem; they probably akshually exacerbate it.)
In the Bun v1.4 video, I promised a certain number of newly passing Node.js tests were added to force us to improve compatibility, and that number is not true yet. The release is delayed until it is true. The PRs to make it true are up but not merged yet. Most likely next Tuesday we’ll do the release of 1.4.
This is a key problem with LLM exuberance: it's very tempting to trade on decades of experience in software using LLMs, because one is tired of typing and manual figuring-out, it seems to work if you're competent, and the payoff is essentially immediate. The real bill comes in the mail much later.
I consider typing to be secondary to software engineering, but I do concede that for those cases that typing really is the bottleneck, LLMs can certainly be of value.
Those cases are rare, though.
I am mostly bullish on AI capabilities, so from my perspective I don't see why we should be skeptical that frontier LLMs guided by experienced devs can translate whole libraries like that. Good follow-up questions would be how expensive it currently is to do so, and whether we will see people branching into all-in on AI versus no-AI camps as happened in this case.
I imagine the $800k or whatever this has cost is coming out of Anthropic's marketing budget, so they can make a big splash about it.
Rewriting a runtime with well-defined interfaces and behavior is quite different from rewriting a user-facing application under active development by a decent chunk of their organization.
To the contrary, I think any problem with this release would be jumped on harshly so they're being more careful than usual. There's not a rush for the community to move to 1.4 and any issues could poison the community trust.
If it was about Claude Code itself, they could have rewritten it. They keep saying they don't even write code any more, so it shouldn't even matter what language it's in.
They chose to use a react rendering to native TUI renderer, which was a source of a lot of performance issues.
AFAIK, they have written a new renderer.
and ho, the bloat, do not forget the bloat, which is technical debt towards the future.
I am not anti-ai per-se, but I consider the software I write as a prouct to add features to and maintain over time. So in this case I think it is not wise to say that bc you got something impressive fast you are done. Now you have bugs, architecture, bloat removal, and others...
Letting an AI manage all the workflow is a recipe for disaster in anything that is not strictly short-term. For this reason, I hardly code one-off scripts myself anymore and I hardly use AI for big things besides discussions with the prompt, reviews and snippets. For adding tests it can also be useful.
For full, long-term products, they try to sell agents, and tokens and the like. I think they do not work well enough what I tried. It always ends up as a bloated unmantainable mess.
Unless something that is totally autonomous (by this I mean 100% autonomous) and automated ever exists, I see writing software that can be maintained by humans still critical. As long as this exists, the productivity upper bound will be that of humans reviewing and driving the workflow, even if with AI support.
I still believe it was the good decision, but I also know that I wouldn't be the first person to run the release in prod.
I think Jarred should start making release candidates instead of releases to take some of the pressure off.
And most executives are figuring this into their calculus right now because they were burned badly during COVID. Meta, Google, etc were loose with hiring and engineers flocked from their lower-paying companies in droves. The brain drain was real.
One public company I was at lost nearly 2/3rds of their engineers and mostly to Meta (granted, they had other problems but it was mostly about money -- the offers were excessive). Then market conditions forced them to freeze hiring and they've had a slow exodus of senior talent since as the firefighting has become constant.
AI adoption has only accelerated problems for them.
We've taken this "only two years and then leave" philosophy to an extreme and now companies are totally justified in not investing in their engineers anymore.
I use more (albeit cached) when centering a div.
I will have to steal it for an upcoming AI tools meeting I have at work.
Also, pretty clever as centering a div w/ CSS has been notoriously difficult to achieve.
I keep seeing this. What is "un-idiomatic" rust?
To actually get the safety benefits of Rust in a real way you have to rework those files to not treat eachother as C code. This is the interesting and the difficult part of a rewrite in Rust, and one that an unsupervised LLM rewrite is probably not even going to attempt.
I don't think this latter stage has actually happened with Bun's codebase. The result of the Rust rewrite in Bun's case is actually less safe than the Zig it is replacing, especially because (I am told) a lot of the new Rust code is unsound (introducing UB).
Why not? A complete test suite exists, so it just boils down to "reimplement this code to reduce the number of 'unsafe' references, while keeping the tests passing" (the last part isn't even needed since Claude loves to run tests and linters anyway).
How odd. Lot of mental gymnastics going on there.
The leaked code of the claude had switch flag where claude pretends to be employee. You can't trust/expect that those PR's were authored by people.
Oh, that company that I heard did not use humans aymore to write software and bragged about it? I heard, correct me if I am wrong.
Something does not match here...
Various people have claimed that Bun in Zig had a lot of tech debt. If they’re to be believed, it seems natural to assume the rewrite does, too. Perhaps all this activity is paying down some of that debt.
The author's assumption is that a rewrite is not just a mechanical translation of code - it's also a state of stability. And no release, for the author (I agree) means no stability.
It's like a developer who says that after a week of work, a feature is 90% ready, but the other 10% is still not ready (for release) after months.
It took TypeScript a year to go from announcing tsgo to releasing TypeScript 7.0. That work was done in parallel; here the work is being done serially — and it’s likely to take much less than a year for a new release.
These are not comparable at all. The bun "rewrite" really is more of a translation of a software that is mainly dogfooded, created with an at best loose regard for a wider ecosystem.
TypeScript 7.0. by comparison is not just a translation from one language to another. It's a true rewrite that at the same time has to consider a massive existing ecosystem (which needs to catch up first or you risk fragmenting it). Plus you might as well consider 6.x part of the effort, since that was the stepping-stone.
Also where bun really is just a runtime implemented with a bunch of glue code plus supporting tooling, TypeScript is much more complex. Change one part of TypeScript and you can get cascading issues somewhere else in the compiler easily. Change something in Bun, and you'll like just break some discrete part.
Hence, the author concludes that rust rewrite is not complete as bun in rust is not released yet.
I agree with author's POV.
I was hoping for more push back against https://bun.com/blog/bun-in-rust - which is pretty thorough and has some decent arguments and reasoning for why they did the rewrite.
This is one of the funnier takes on the rewrite. Bun was held up as a flagship Zig project for years. Then they chose to rewrite in Rust and everyone up to the Zig author has suddenly switched to claiming that Bun was terrible code all along.
Perhaps. But were that the case, one would think they'd be quite eager to say so.
Are you expecting them to live-tweet their work or something?
why shouldnt upcoming work be as public as the rewrite itself was?
What a time to be alive
It means shrewd.
E.g. we should keep our wits about us when someone is making big hyperbolic claims about LLM that they directly benefit from, because maybe they have a motive to mislead either themselves, or us
Thankfully now I have some good material to post-rationalise my intuitive dislike
We can't have commited and involved people working on opensource stuff and simultaneously avoid drama when their sence of identity/beliefs/pride is devalued.
If you're being pedantic, no it's not "done," but nothing ever is.
One single product, AFAIK, and one ladden with bugs and issue too.
https://news.ycombinator.com/item?id=49069383
EDIT: I'd love to hear why I'm downvoted.
I shouldn't be surprised though, of course. Giving any credit or slack to a high-valuation LLM company is a silly endeavor.
You and me both friend!
That’s peanuts, if not the shells of the peanuts, for a project and company of this magnitude
- just because it doesn’t help 99.9% of the companies today it doesn’t mean it won’t help them tomorrow
- 0.01% of the companies employ a much bigger percentage of people
- 99.9% of companies won’t need to do a project of this magnitude