Hacker News new | ask | show | jobs
by Eufrat 28 days ago
Some people, myself included, think that announcing a conversion from Rust to Zig as an experiment then jumping to putting it in the alpha train for public testing/consumption without any real explanation in the span of around 2 weeks is irresponsible and reckless.

Blogposts were promised, details were hinted, but no, it’s just full steam ahead because the AI worked so well. The converted unit tests all worked, all the synthetic tests are okay, so what are you complaining about?

At some point, it’s less about the technical questions and more about getting that pesky human buy-in.

4 comments

They are looking for a different human buy-in.

"Yes, the AI rewrote the code. No, we do not pretend that we've scrutinized the code, or that we understand it. It works, tests pass, so we don't care, and so shouldn't you."

The "recklessness" is offered as the new normal. Because it kinda, well, works for them.

The recklessness kinda works for everybody until some point. Go fast and break things... then cash out before investors realize, unless you manage to capture the market so you can keep breaking things because people will swallow.
What's working for them is having a huge amount of resources and very good people to design a cutting edge agent harness, RLHF the hell out of their models, and build out a tremendous amount of inference capacity. I'm sure their process for making code changes in any of their client apps is very fast, but a TUI built around a chatbot is also not a particularly complicated application. So yes it's working for them, but the vibecoding that they are selling is clearly not what they are doing in practice.
They’re not talking about the chatbot TUI. The chatbot TUI was and is in JavaScript. They’ve ported the JavaScript runtime.
Yes, and it's working for them, but it's not their core competency nor does it have much to do with the actual product that people pay them for (apart from being a source of bugs to avoid), so the fact that it's working for Anthropic doesn't necessarily imply that it's actually a good idea in general. It's working for them, with emphasis on for them. Or it's actually a demo of the future and it would work for anyone, who's to say? There's no doubt that AI (and especially Claude as industry leader) helps you carry out significantly more complicated side quests than in the past, in part by enabling that "recklessness" with surprisingly little risk. Maybe an exhaustive enough test suite is really all you need. But Anthropic is not in a position to demonstrate that as the universal future of all things, not just side quests.
Not GP but the js runtime has a long tail of case edges you simply can't emulate with a single app.
It surely does. I’m also extremely worried about the way they’ve decided to go with the port.
What does Bun’s governance look like? Now that Anthropic bought the company are there significant external contributors that would expected to have input on a decision like this?
And why buy it when they could have just called it Run and do the Rust conversion anyways? The license prohibits it, they don’t need the team’s expertise anymore, since they’re running full AI vibecode mode. Makes no sense to me
Seems pretty clear that they do need the team, to direct the LLM effectively.

Also they're probably interested in the team just as an acqui-hire of good developers, and they're probably interested in the marketing value of converting the actual bun to rust via LLMs. But mostly I'd assume it was about needing the team to effectively direct the LLMs.

IMO it’s reckless to not pin down ones dependencies. No need to pull the latest experimental hotness
I get that and I can see an argument that they didn’t really put it as stable, but I suspect the reason it is not the stable version right now is from the massive pushback as other projects and companies started pulling support for Bun because of the loss of confidence rather than any other reason.
How about testing the output? Seems like the ultimate test. If the output's still good, I guess the rewrite didn't hurt.
Kindof.

The problem is: quickly fixing problems (or preventing problems) benefits from having a good understanding of what the code is doing.

If you do have a suite of automated checks that's comprehensive enough that if it passes, no one will have any problems with the result, I think I'd agree. -- I don't think we're quite there at the point where "programming" is coming up with that suite of automated checks and then just not regarding the source code of the program itself.

Testing can expose errors, but it can’t prove correctness.