At least people use Rust and AI
Unlike Zig :^)
An AI rewrite of a popular Anthropic-owned JavaScript runtime and toolchain has sparked praise for the speed of its execution, but also criticism of the coding practices behind the project itself. Last week, Bun creator Jarred Sumner announced that he ported Bun from the Zig programming language to Rust in only 11 days, using a …
So name us any “noteworthy” SQL project. Or a bash one.
That is, I think maybe the downvotes are because of the implied assumption that there must be “noteworthy projects” — i.e, presumably, open-source projects —for a language to be any good. There are probably billions of lines of company-internal, often business-critical, SQL and bash code. But no “noteworthy projects” that I know of. Still doesn't mean that bash and SQL suck; on the contrary.
So what exactly does it mean that you know of “only” two “noteworthy projects” in Zig?
A: Nothing. It means absolutely nothing.
If it's so great, why does software quality seem to be *decreasing*?
The reality seems to be that like any tool it's only as good as the monkey wielding it, so some will use it under supervision to enhance their output, and others will use it as a lazy way to get jobs done.
Ledt to it's own devices the results may be... unpredictable. And just because you've got lots of tests passing it doesn't mean it works, just that it passes tests.
And if you've got a (literal) million tests then it's fairly obvious they're not going to be great, it's going to be generated dross. Likely written to pass and with all sorts of duplication.
If the tests meant anything there'd be zero bugs and it could've been left alone.
Also not a great sign that the thing started with 500k lines, and ended up with twice that. That's a *lot* unreviewed code, and just a lot of code full stop for something that isn't *that* complicated.
“Bun is a JavaScript suite consisting of a runtime, package manager, bundler and test runner. Some developers like it because it is a fast one-stop shop that plays well with Node.js. ”
Wow… a million lines of code for that….. and to think they squeezed BBC Micro original Elite into 26K.
I was actually impressed with Kelley's response, to be honest. He outlined the problems he saw with the codebase, weighed in on how the breakup would impact him financially, stated his principles to be more towards maintainability and sustainability, and acknowledged that both software projects had divergent values, and framed his disapproval as “I myself do not want to do what Bun was doing“.
Sure, he had a few zingers and bon mots for Bun's team, but he ended the missive in ways more kind than I myself could have managed:
While I resent Jarred for making Bun into an embarassment for Zig, and I blame him partially for some of the slop we've been dealing with, and I stand by my criticism of his leadership, I also empathize with him. He has different values than me, he wants different things out of life than me. But I think he's actually happy and successful exactly where he is. He figured out how to accomplish all the stuff that he wants. He gets to live out his productivity fantasy fever dream, he's probably already super wealthy. He has minor tech celebrity status.Honestly, I think he did well for himself, and despite my feelings of resentment, and despite the fact that I find myself battling the marketing arm of Anthropic, I don't wish him any ill will. Even in the midst of my frustration, I am happy for him and his success, by his own standards.
This blog post has been characterized as a personal attack against Jarred, while I originally framed it as telling the story of a failed business relationship. My framing didn't work because I had unprocessed emotions of resentment, that were obvious to the reader, but not to myself. I've updated this conclusion section after self-reflection and chatting with friends. Feel free to go look at the original text in this website's public source repository.
I mean… it's a low bar, but I've not seen a lot of software leads at least try and process how they've been feeling about the whole situation. I'm giving him props for that, at least, in these degraded latter days.
> I mean… it's a low bar, but I've not seen a lot of software leads at least try and process how they've been feeling about the whole situation. I'm giving him props for that, at least, in these degraded latter days.
It is a very, very low bar. Regardless of the validity his complaints have the post comes across as incredibly immature. I look forward to the day when programmers in general develop emotional intelligence but I’m not holding my breath.
AI developed code bases will be impossible for humans to maintain, so they'll be forced into pay ever escalating token pricing for bug fixes and feature additions to their existing AI slop.
Even if it works as far as passing all your tests if it is twice as big and therefore at least twice as slow a lot of that cost is being passed onto the people who run it. Imagine if you had an app used by 1 million people per day, now suddenly it uses up 2-4x more battery and their phone gets hotter while it is running. They may not notice or care about AI having written it, but they would notice it drains their battery more if it is something they run a lot like a game or social media app, and they would definitely notice it if it makes their phone hotter. They are more likely to abandon it not because of the AI authorship per se but because of the crappy performance. Suddenly a year later you find you have only 500K users, and you have to pay the ever escalating AI development costs across half the revenue.
Perhaps it is broke but not in the way you think.
There are a lot of tools written in Javascript and every time you run them, NodeJS has to kick off, parse the source, execute it and suffer all the issues of a high level language. That's a lot of wasted time, memory overhead which translates into cost.
So some tools are being replaced with natively compiled equivalents. For example Babel is being replaced with SWC (Swift Web Compiler) which is written in Rust. And even the Typescript compiler is getting a rewrite in 7.0, in Golang.
So if Bun is some honking big tool written in Javascript and every time you invoke it, NodeJS kicks off and parses a bunch of source and puts an overhead wherever it runs then it becomes a problem. That does not mean allowing an AI to shit out a compiled version is necessarily a good idea either. From the way it was generated it sounds like a ludicrously rushed attempt. A more curated and guided port with AI might have taken a bit longer but lead to code that humans and computers alike could maintain.
> every time you run them, NodeJS has to kick off, parse the source
This is not true. Node.js has supported the V8 code cache for a while now, and even before then, there were unofficial ways to do it, like the v8-compile-cache npm package. You only pay the cost of lexing and parsing the source code once, then the bytecode gets cached, assuming the caching is configured correctly.
If anyone thinks the problem with software development is AI, they clearly haven't been involved in the industry over the last 20+ years. The problem is one of competence (and lack thereof). And in the last 15 years or so, an increasing number of software projects have been led by non technical people who have perhaps been on a 3 day scrum course and are under the deeply misguided impression that they know the first thing about software development (they don't, but they do know how to have LOTS of pointless meetings to make it look like their busy and to feel important).
AI is actually the solution, as it allows people like me to develop systems in days that would have taken me or a team years. But the old maxim still holds, even with AI: garbage in, garbage out.
I've only used AI for small functions that I can review properly. Mostly just the stuff that's a PITA to write.
If you spend $165k to convert this, what happens when you want to make a change? Does it start all over again or do you send over the existing code as the prompt? Surely that large a prompt is going to cost a load all over again?
Is there something 'clever' in the background or does it just keep getting more expensive?
Its pretty much the same as any developer working on a large project. The tools try to locate the relevant code via a combination of searching through the documentation, looking for keywords in the code, reviewing git history and/or tracing a known bit of code through until they (hopefully) find the right location(s) to pass to the LLM to comprehend and modify. And then compiling and running tests to see what they have broken.
Like humans in a badly structured project they will miss bits, sometimes undetected, particularly if the code is badly structured.
That's horrifying to someone who learned programming languages in the last century. It's an approach that a pathologist would take with an organism that shows observable features, but has biological processes that the pathologist does not fully understand. "Let's see, that anomaly is due to this protein, dunno which gene encodes that one, dunno quite why it's expressed right here, umm, maybe the problem is hormonal, or there's another organism involved, or a virus, or..."
That's one of the big cons for AI: it encourages and empowers people to do work they have no business doing. And then, when they get thick in the weeds, and don't have the mind to properly diagnose and understand the issue, their first action is to... further prompt the AI.
So you have a vicious cycle of AI writing bad code confidently, then having it find and fix the issues it created by writing more bad code, which introduces more issues...
On top of which we don't know that $165,000 is the true cost of the job. We only know* what Anthropic (which is said to be losing money a an impressive rate) is charging this month.
* In this case, what we "know" is merely an educated guess that could be way off rather than an actual invoice.
I've used Claude Code a lot and my experience is like a coin toss - sometimes it gets things bang on, or near-enough, other times it totally misses the point or does something superficially okay but adds technical debt. . You really need to know what YOU are doing to know when it doesn't know what IT is doing.
I do find that it works better with an existing codebase where it has context and rules to follow. AI is also useful for donkey work - I told it the other day to write some line intersection tests against a complex shape with a bunch of scenarios and it just did it and saved me an hour's work. I've also asked it why a bug was happening and it found the fairly obscure reason with some coordinate code where I was using a y instead of an x.
So AI does have uses and it does augment understanding providing you pause to understand. But letting it loose in a massive project with minimal guidance is asking for trouble. Even if it passes all tests, it will be a unmaintainable mess of code which cost a fortune to wrangle with AI.
The difference between LLMs and humans looking at a SO answer, is that we internalize things in a much more complex way.
For us humans, we internalize, we process, we apply logic and reasoning [and emotion] to our learning. And when we write code, we build upon a foundation of understanding and shared knowledge even if, yeah, we totally copied a line or two from that answer.
The LLM, though, doesn't have such grace: it has no inspiration, no complex logic or reasoning. It copies verbatim from hundreds of thousands of sources simultaneously, each "inspiration" carved into the model with unknown licensing or attribution, with as perfect a memory as it was trained to have. That training is a game, where good-scoring outputs give more weight to the respective input, not a logical thought process with stakes.
These are the fundamental issues with models today, and they can't be easily fixed. No matter how benign your use case.
One has to admit, a lovely backhander.
All the better for being largely true in so much software. (I have no idea whether this actually applies in the case of Bun or just a bit of gratuitous slagging off.)
LLMs = lovely loads of mucky slop
They started with a 500k line, poorly architected, buggy codebase and converted it into a 1m line, poorly architected, buggy codebase in a different language. I'm not sure that's the win it's being portrayed as. It seems a bit like shuffling the deckchairs on the Titanic while opening all the portholes.
Any developer who now needs to maintain that code will essentially be coming in blind. It's bad enough maintaining code you've written - but at least you've got a vestigial memory of what it does - doing it for someone else's is hateful.
Slightly tangentially, one of the reasons we have such poor software nowadays, especially as to how it's architected, is due to the obsession with the Minimum Viable Product (MVP). This insatiable need to get something - anything - to market means that rather that including ways to deal with future plans everything new is just a bodge onto the existing codebase.
We all rightly decry feature- and scope-creep as a bad thing, yet using the MVP model means that it's inevitable. To make an analogy, it's how you end up with a Morris Minor with 8 wheels across 3 axles, 9 doors (just on the one side though), 2 engines (running in an active-passive pair) and an integrated greenhouse that rotates to follow the sun.
Both are great ideas. Just complete a change-improvement request form and, assuming we have enough sprint-points, your features will be added. We won't actually check if your features are suitable or necessary, our only concern is that you completed the form correctly.
From the article - 'The job took 11 days and cost about $165,000 at API pricing.' and '“There’s absolutely no way an engineer with that salary would’ve been able to achieve the milestones Claude did in 11 days,”'
11 days at ~$165k. Lets see, say 10 working days to do this one job. 165/2=82.5*52=4290 - $4,290,000 per year salary. Nice work if you can get that!
I think the idea is that if you're paid $165,000 a year then it would still take you more than 11 days to convert 500,000 lines of slop in one language to 1,000,000 lines of slop in another.
I don't know your slop output, it might be that you could do the conversion in a year, in which case the cost would be the same.
Translation from one language to another is, per se, just a matter of syntax. And syntax is, per definition, just a regular pattern that your code has to conform to, in order to be syntactically correct.
Hmm, les’see, where have I heard that before — “regular ... pattern”. You can come up with, and apply, quite a few good regexes in eleven days.
It is going to be an interesting issue: do you pay someone $4.3m Pa with them paying for their use of AI, or paying them at rates aligned with current developer pay and the business incurs the highly variable cost of AI.
I think the stage is getting set for some companies to be burnt and potentially bankrupted by poor use and management of AI costs.
If it was 500,000 lines of code originally you're looking at probably a 6-12 month project at least to convert it by hand. Probably for 2 or 3 people including test cases. But there is no doubt in my mind that AI could have done a better job if it were properly supervised and I wouldn't have much confidence that somebody telling an AI to shit out a port in 11 days is supervising much of anything.
So here we are at the transition moment in time, when AI slop becomes a least better than human slop. From here on, humans will remain split between good and bad programmers, while AIs continue to eat their way up the league table. Pass me the popcorn. >Agh!< No, not the slopcorn you idiot!.
“There’s absolutely no way an engineer with that salary would’ve been able to achieve the milestones Claude did in 11 days,” an impressed HashiCorp co-founder Mitchell Hashimoto noted on X.
HUH?!?! Blowing $165K in 11 days amounts to $15K per day. Figuring a US work year of 250 days, that annualizes to $3.75 million per year. I don't know any engineers making anything close to that kind of money.
The real questions are:
1. Could you get a team to perform that port in 11 days? Probably not. If there is a team already primed for translating from Zig to Rust with knowledge of Bun, there is the possibility of a rapid port, but completing it within 11 days seems unlikely. I'm a distrusting sort, so I can't help wonder if there might be some accounting generosity involved in the existing 11 day claim.
2. Could you perform this port for $165K or less? If you look at senior engineers in the US at, say, $250K per year (middling figure -- finance pays better, higher cost-of-living areas pay better, a lot of areas pay worse), then you have a convenient $1K per day figure. Can the task be accomplished in 165 staff-days? I can't say. If you elect to use a country with lower wages, and there are a number where you can pay 1/3 or less, then you buy more time. Could the task be accomplished in 495 staff-days? That seems more likely.
What I don't quite understand is how moving a large amount of code to a new language and creating a massive new code base with which no person has any degree of familiarity is a win in any sense of the word. Unless one commits to having AI manipulate the entire code base moving forward, the lack of understanding is a serious problem. If one does commit to having AI make all changes to the code base moving forward, one is stuck with employing a $3.75 million per year engineer. That might make sense if AI can replace your entire engineering staff, but otherwise I don't see how applying this approach generally does anything but bankrupt a company.
"Could you get a team to perform that port in 11 days? Probably not."
If the code is documented line by line, in several small modules and is in great shape, and everyone knows exactly what to do - in theory. Considering this is 500k LOC and descibed as being already sloppy code - IMPOSSIBLE.
Depending on the coding project, there is a sweet spot in the number of people in the team. "You can't produce a baby in one month by getting nine women pregnant"
"If you elect to use a country with lower wages, and there are a number where you can pay 1/3 or less, then you buy more time. Could the task be accomplished in 495 staff-days? That seems more likely."
This really depends on your business case. Do you produce software that makes money? If you can produce working software in 11 days for 165K and it brings $1000 per day, in 495 days you have lost the $165k in wages AND $495k in lost profits. With this AI you would have lost only $165k + $11k.
Let's keep in mind that Bun is owner by Anthropic - it's there in the article - and Anthropic likes to peddle Claude into coding projects. This is more of an advertisement puff piece since the business case here is weak anyway.
It is not 11 work days though. The bot will work 24/7 but after meetings, lunch, breaks, etc a human might get 6 hours of productive work done in a day at best so it is actually 44 work days.
It is also not a single bot either but a team of unspecified size - "using a fleet of Claude agents running in parallel".
But a team of bots taking 44 work days doesn't sound so good on Twitter I guess.
Hmm, so multiply by 10x or 20x to get the "actually profitable" pricing and considering (based on the article) that it's doubling the LOC while producing an unmaintainable mess... it's really not that impressive, is it? How long would this job have taken on my local computer with a 4090?
The referenced response in the bowels of the article from the Zig boys casts quite a different light. Notably, it's written in the style of a highly competent developer & dev.manager.
I find it FAR more realistic & informative than the rah-rah announcement.
A sample:
>We became increasingly horrified at the programming practices we saw in Bun's codebase. Hacks on top of hacks. Abuse of assertions. Most of all, recklessly speeding past feature after feature with very little time taken for reflection and elimination of bugs and technical debt.
>Jarred was already writing slop well before he had access to LLMs. [...]
>We made futile attempts to guide them towards better programming practices.
Basically, Sumner is a scriptkiddy.
Note the closing section pointing out some glossed-over low-level technical items, which are actually quite important.