I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.
Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify hiring a SWE for 200k. I will say, at the very top for a software heavy company like Google or Anthropic, they will still hire excellent engineers to create new software that AI is not very good at.
But for companies where software is simply a cost center. Like Walmart, or Target, companies that were already outsourcing software development, or using cheap H1bs, now they have the alternative of AI which is much better than even hiring an average software engineer for 200k. This is a sea change in the job market, it’s going to have a pretty big effect as it is right now. US has around 1.6 Million software developers, this number is going to get cut drastically, the very top, say an L6 quality in FAANG will be fine, the average in a no name Bank, or the guy building the website for McDonalds is out, he needs to learn something else or he’ll end up without a job soon.
I would not have predicted this a year ago, now it seems clear that this will happen. Just shows how much of a sea change we have witnessed just like that.
"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of total resource consumption."
jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers.
as programmers are not the resource, the program is the resource, programmers were the means of production of said resource.
stated differently: in a world where you dont need programmers to make programs, there is infinity of programs, and no jobs for programmers.
You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs.
A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in the amount of software being made.
yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so on.
of course I am likely wrong, people say: its never as good or as bad as you think.
While there are a lot of resources being poured into improving and integrating tooling and use cases and increasing model sizes, the leap between the models you notes are not as much as you think it is. It's the same tech that's scalable to a certain limit of diminishing return. It's a recurrent pattern in technology.
> yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
Yes, perhaps one day. Probably no other "job" as they are today will have the same shape and form. Cancer will be cured and fission will be solved. We may even crack teleporting. Let's hope these all happen and the outcome is not detrimental the livelihood of humans.
Sorry, but I don't think you understand how many different skills are involved in building software that large companies can actually rely on.
Writing code is only one part of the job. I use Claude Code every day and I love it. It has made me much more productive. But I still have to guide it carefully, review every change, and fix the bugs and poor design decisions it introduces.
Personally, I'm looking forward to retirement. I expect there will be no shortage of consulting work helping companies clean up the AI-generated mess generated by inexperienced developers and overconfident middle manager with zero software development experience :)
It is possible because they hired the original author of Bun to do this.
It won't be possible to HIRE anyone doing this job confidently, they won't even know if they f*ked up.
I am not too worried anyway, one person with no context, with or without AI, can't do this job. Just like with all the AIs you have, giving you 10 millions, you still can't build a AAA game, it is that simple.
It is highly debatable if a 200k cost engineer that is suitable for the job wouldn’t bring in more value.
Also it is debatable they got any value at all from this. Anyone who wrote unsafe rust and also wrote zig would know that unsafe rust is much much more unsafe in comparison
It's only 4% unsafe and most of it is single-line pointers that came from C++
> At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.
I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or C++.
I'm not so pessimistic. There is an infinite amount of work that could be done. No one would have entertained the idea of rewriting a project in Rust before this. It hasn't replaced anyone's actual job and they still had to hire a high paid employee to pull it off.
I suspect rather than hire less people we will just produce more code changes.
But do the markets care about a Postgres in Rust? Probably not, or at least not right away. It is a long way towards commercial success.
> I suspect rather than hire less people we will just produce more code changes.
Why? Towards what end? Code changes are output, not outcome. It also needs to be connected to someone willing to pay you hard cash. That is the hard part, a race to the bottom, and the reason I also believe there will be downwards pressure on salaries and even employment.
> No one would have entertained the idea of rewriting a project in Rust before this.
I largely agree with your comment, but is this sentence typo'd or something? "Rewrite it in Rust" happens so often that it's become a meme (and that was so before the rise of agentic coding).
Maybe you meant to say that nobody would have entertained the idea of rewriting this project in Rust?
It's funny, I see the opposite and I would only trust a senior engineer with conducting such a wide-reaching change. I would be more likely to hire a senior engineer who might now be able to effect such change.
Exactly. AI opens up a massive development frontier of projects that were simply impossible before. It does differentiate though. In the old world most "software engineering" work had nothing to do with software engineering so being highly skilled, educated, and experienced in software engineering made very little difference in compensation, position, promotion, etc. "software engineer" isn't a real thing anyway. coding is a secretarial job. you have to move beyond the mindset that coding is doing something useful. it's not. it is a means to an end and now better means exist. if you want to be an engineer you have to think in terms of systems engineering and building systems that deliver defined externally testable capabilities. in a few more years the idea of reading and writing source code will seem as absurd as reading and writing asm seems today.
> They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.
All that really proves is that you’d be an astoundingly poor choice to hire. If you’re spending $200k on someone that doesn’t know at least two out of three (context, Rust, or Zig), you’re just burning money.
That’s not to say that experienced engineers familiar with the stack would or wouldn’t be able to do it in a year, but they’d certainly have a better shot at it.
It’s also not that this project sprung into thin air from a quick prompt and LLM magic… it was driven by a dedicated, highly talented, subject matter expert with extensive SWE background and extensive support from the leading experts in the world. You’ll continue to need someone to steer the ship, even in the Wal-Marts and Targets. An LLM is only ever as good as the input it’s given.
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.
And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swept away (not even treated as unsoundness), if you actually look at the code and the summary.
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
Can't assume good faith in you at this point but I'll explain it.
- They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SAFETY comments in code.
- I only spent ten minutes and found two code patterns that are wrong with little exceptions. Also randomly checked a few samples and there was no exception. This basically means that failure patterns not explicitly picked and disallowed will repeat themselves over and over. Try imagine the more subtle ones hiding in this huge codebase.
- Trivial to find != Trivial to fix. 107 of the problems (one of the categories) are borrow issue and requires large refactoring (rearrange and rethink whole modules of code) to be removed completely.
So yes, huge regression by my standards. And I'm not questioning Rust the language. I'm questioning Claude, Jarred the person, their dev & marketing practice and the Bun project.
Btw these categories are separate from the (still unfixed) category of problems I mentioned 54 days ago in the comments before.
Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.
That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough.
Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
> They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port.
I'm not sure that this is true - who says that the same invariants weren't broken on the Zig side? (Aliased pointers are UB either way, for example). Also, "unsafe invariant broken" does not strictly mean that there's a reachable bug. It should be cleaned up though, obviously. But in theory, callers may never actually trigger a bad invariant in an unsafe block.
Regardless, even assuming that these are genuinely new bugs, it doesn't change my point. Going from ~X known bugs to ~2X potential, grep'able bugs, is a win to me. Sounds like it isn't to you. Great.
> Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
I'm obviously not intentionally ignoring anything, if you think I am then you can stop responding.
There wasn't a reply button on your latest reply so I'm posting here instead. Also because I now have more time to clarify what's exactly wrong about the claims.
> who says that the same invariants weren't broken on the Zig side
There are no such invariants in Zig.
> "unsafe invariant broken" does not strictly mean that there's a reachable bug.
Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
> callers may never actually trigger a bad invariant in an unsafe block.
There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
> potential, grep'able bugs
We are indeed going in circles but I have to ask: you still don't understand that? Grep works for violated lints, unsafe blocks and all things explicitly exist in the code. Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools. They also have thousands of those. It's unfair to say the unsoundness is freshly introduced by the port, but Rust also doesn't help in this way where no unsafety is encapsulated and calling anything can be a wild ride.
Zig does have invariants. It doesn't have an aliasing invariant like rust though, but it does have its own invariants, naturally. Zig is a memory unsafe language.
> Broken invariant literally means you are reaching it. The word you are looking for is "unsoundness".
A reachable bug means one that can be triggered. Undefined behavior does not mean a bug can be triggered.
> There's a neat class of UBs called "immediate UB"s. They can ruin the code just by being compiled, instead of reached at runtime. And guess what? They have a lot of these.
Can be, yes.
> Not for unsoundness in safe functions that can be called incorrectly and ruin everything, can't be reasoned about by any existing tools
This is only possible if unsafe is used. `unsafe` is grep'able, hence all memory safety bugs are grep'able. That's the whole point of rust.
> `unsafe` is grep'able, hence all memory safety bugs are grep'able.
Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No. Even assuming everything is done idiomatically, memory safety bugs can still originate from unsafe blocks and all the safe functions in the same module. So we want the module containing unsafe to be small and closed. Otoh with this code base unsafe lives in every module.
Making them encapsulated is the whole point of Rust, in this code nothing is encapsulated so no, they missed the whole point of it.
Aaand it's not like you can just remove the unsafe blocks one by one trivially. It's as hard as rewriting the codebase from ground up without reference (unlike the current migration) as every referenced object in the call graph needs to be reordered. Well partly because the original code sucks I assume.
> Not these in particular. You are again ignoring the context.
What context? I just said afterwards that aliasing is not one of those cases.
> Undefined behavior are bugs by themselves. Let's check if you are holding any of the wrong assumptions:
Nope and your post wouldn't justify the statement. Not all UB leads to a reachable bug. The blog post doesn't say otherwise, and in fact it indicates exactly this (that UB can compile "correctly" one day and "incorrectly" the next). Check the errata on the post.
> Wrong implicit premise: "all memory safety bugs resides in unsafe functions/blocks".
No, I'm right other than l-unsound. Saying "but safe code that references unsafe code" doesn't change that.
> It's as hard as rewriting the codebase from ground up without reference
Not necessarily. At least multiple cases I've seen in the rewrite would be a matter of just moving `unsafe` from one spot to another and then placing the assertions at the caller.
This conversation is increasingly dumb. I've made my point repeatedly - moving to Rust means memory unsafety violations can be grepped for and that's not up for debate. You can say that that's not sufficient as a win for the project, I really am ambivalent.
That's untrue. It has already been maximally dumb since your first comment with the various logical fallacies you managed
to carry out in a single sentence. The only reason I'm still making my replies is that you are making so many false claims
that may mislead someone else.
My claim is that you can grep for memory safety bugs in rust and you can't in zig, therefor trading memory unsafe zig bugs for memory unsafe rust bugs is a good trade. This has been my claim, it continues to be my claim. Linking to the nomicon won't change anything just like linking to the other blog post changed nothing (and you literally misunderstood the other blog post, and I even pointed you to the errata of that post).
Yes you are. Either that or you are too distracted to read or you wouldn't be repeating
> ~2X potential
at this point. That's what I've found in 10 minutes. And they are actual bugs that I've take extra time to (statistically) verify. Please worship me as the new machine god if you think I've found all the bugs with a glance.
And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
> And they are actual bugs that I've take extra time to (statistically) verify.
I'm confused. You said that you've just grepped and found some undefined behavior. What do you mean that you've statistically verified them?
> And I'm not going to debunk each of your false claims, when you are doing that at the expense of appearing either dishonest or ignorant. I'm allergic to apologism.
My false claims? Like that pointer aliasing is undefined behavior in both languages? lol okay?
> Additionally I'd admit that I've intentionally avoided talking about the specifics of these problems, giving links to each of them or something. That's for a concrete reason - I can't bear it if Bun gets (even in the slightest bit) better because of my contribution. It would be one of the worst things I can do, morally.
I'm taking all of your claims at face value, I haven't said that you have to provide evidence of them. I'm not saying that your claims are false, I'm saying that I can grant them and still disagree with you.
I don't know what to tell you. Even if you said that those 2x bugs were 100% verified, I'd still say that this is a win because you can grep for these bugs now. That is obviously better to me.
Instead of "possible" undefined behaviors, potential bugs, the samples I've randomly picked are all actual undefined behaviors, real bugs. Hence statistically.
> pointer aliasing is undefined behavior in both languages
That included and also basically every other claim in that comment. I'd be happy to learn otherwise if you have concrete evidence.
[Edit: erased information that can help people find the bugs without prior knowledge]
> I haven't said that you have to provide evidence of them
Sure, but if I'm going to it would be a lot easier to convince everyone how bad it is (just like I did in private message groups). I can't take the risk that "everyone" also includes Jarred though.
> you can grep for these bugs now
You can grep for the greppable new bugs. I raised them as an argument because these issues are glaring. What about the ungreppable ones? More than half (again, randomly sampled) unsafe usage in the 10,413 unsafe blocks in current Bun looks iffy to me. I just haven't taken the time to verify them because many requires reasoning across the code base (see? the exact problem Rust ought to prevent). From a Rust point of view it's a huge failure.
All these while considering that the Bun agents (no people at this point I'm afraid) don't even know how to grep for the easy ones.
This is going in circles. I think my point has been made. You can grep for every memory safety violation in Rust, that is a win. Pointer aliasing is apparently not UB in Zig, that's cool, assuming that's what you are referring to - but I just can't stress enough how little this matters to my point.
- They had an existing functional Zig implementation
- They had an existing test suite for the Zip implementation
- They had a separate JavaScript compliance test suite with ~ 1 million tests
- The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architecture and problems
I don't think that middle management at most companies is going to be starting from that same point when it comes to building or updating something. Generally, I don't think there are many projects out there that have such robust existing tests and specifications.
In this case, the engineering behind the tests and specifications need to also be considered part of the process, since without those you wouldn't be able to build a control loop in the same way.
You are missing the big picture here
The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster)
Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
and btw, if it can write code, it can write tests and test suite
Ai has come a long way, 2 years ago, this task would be impossible ! 1 year ago, it would hit a dead-end in the first hours of the execution
This blog post is nothing short of an amazing and fascinating tale, yet in some aspect very very scary ...
No I'm not missing anything. The existing specifications and tests provide a huge validation surface to work against for this kind of migration - they're the foundational pieces of the control loop. Without those two things, this kind of rewrite would not be possible.
We have known for decades that the hard part in programming isn't programming, it's making sure you have the right target! Bad designs and bad specifications have caused more bugs and broken software than anything else, and the time taken to develop the testing and validation suites (that is - the javascript spec tests) this rewrite used must be considered part of the engineering effort.
> and btw, if it can write code, it can write tests and test suite
You must be very early in your career. Again, the hard part is not writing the test, it's knowing which tests to write.
> You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
It would help if you actually engaged at all with any of the points they just made. They were good points!
Not only that. I think most of us, including the author wouldn't have thought this was actually feasible.
Not only is the time and dollar spent lower than a lot of people expected. We could now foresee a lot of these human interaction, mistakes, time and cost could be further reduced by a factor of 2, 5 or even 10+ in the not far future.
Also worth taking into account what is stated in the blog post is also acting as PR piece for Claude and LLM in general.
This project is very well suited for AI. It's not clear to me if AI is nearly as good or cheap when building things that are new, where it doesn't have an existing target to match and doesn't have an existing test suite to bounce off of and has the benefit of being lead by an actual human with a very intimate understanding of the codebase.
I am seeing the complete opposite. 200k senior engineers can now do large scale projects way beyond what they could do just a year ago. My company is now able to implement stuff that we used to only dream about. Having 200k senior engineers who master AI coding is a true super power.
> I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year.
Sure, if you're wasting money in silicon valley. They could have hired in Europe and got three people for $300k, which is only double what they spent.
I think the time is the really significant factor, not the money. I bet if they had the option of paying $300k to have it done by humans rather than AI, but magically in a week instead of a year, they would have gone for that instead. $300k is nothing to Anthropic.
Opportunity cost is not a real cost. No money leaves your bank account. It is a decision making tool, and treating it as an actual financial cost is a misuse of the idea.
It’s literally the price of lost opportunities. It’s not understood to be a financial cost. It’s exactly what it says on the tin. Lost opportunities may not be a financial cost, but they’re certainly a cost.
Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify hiring a SWE for 200k. I will say, at the very top for a software heavy company like Google or Anthropic, they will still hire excellent engineers to create new software that AI is not very good at.
But for companies where software is simply a cost center. Like Walmart, or Target, companies that were already outsourcing software development, or using cheap H1bs, now they have the alternative of AI which is much better than even hiring an average software engineer for 200k. This is a sea change in the job market, it’s going to have a pretty big effect as it is right now. US has around 1.6 Million software developers, this number is going to get cut drastically, the very top, say an L6 quality in FAANG will be fine, the average in a no name Bank, or the guy building the website for McDonalds is out, he needs to learn something else or he’ll end up without a job soon.
I would not have predicted this a year ago, now it seems clear that this will happen. Just shows how much of a sea change we have witnessed just like that.