Posted by tomlockwood 10 hours ago
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.
Writing code is a different thing.
Not necessarily. Didn’t Microsoft port the TS compiler to Go and they did it by translating the TS? It wasn’t idiomatic Go.
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.
It was purely about maxing your compensation because changing jobs nets you more than promotions & raises.
I've never met an engineer in my life who truly earned a promotion every year and very few every two. Very few companies have org charts that even support that or have that many levels. This logic/advice only really applies at a few companies and people have adopted it no matter where they work. There's not enough growth/hiring at 95% of companies to even come close. The Peter Principle is also a real thing. Everyone's competence has a ceiling.
There's even an implicit understanding of this that people at smaller companies have inflated titles and you typically rank them down 1-2 levels when hiring/acquiring at larger companies.
Now I do agree that companies haven't been investing in their engineers, but that doesn't also mean this isn't a vicious cycle. Employers and employees are in a mexican standoff and things are only going to get worse until one side comes to its senses. Employers have all the leverage for it to not be them.
For the vast majority of companies the average tenure of an engineer sits between 18 and 30 months. They're also mostly hiring young engineers in their 20s. As an employer what is your upside to making such investments before they're at least mid-career? A lot of people seem to want the world and offer nothing in return for it.
You don't view it as a problem that companies consistently compensate new hires higher than they are their experienced employees?
Hell, I would have been perfectly happy to never change employers in my entire career to date, if my salary had anywhere near kept pace with my peers who were job-hopping.
It depends on the current employee and the incoming employee. They are not interchangeable cogs. Also not everyone consistently provides good value over their tenure -- a lot tend to work hard early and then for various reasons taper off. It's not necessarily their fault, but companies definitely are aware of this.
Personally I tend to value growth of my skillset over growth of income and that has largely informed my movement. I move when there's no longer interesting work if the compensation is at least fair. I've never been about comparing myself to others -- especially when most of my peers' left the industry after 5-10 years.
And you don’t think that has anything to do with incentives (or lack thereof)?
> I've never been about comparing myself to others
Doesn’t have to be about comparing oneself to others. More about the cost of living increasing because software engineering salaries are rising around you…
No, that's almost never it. It's mostly life circumstances, burnout, frustration with management, etc.
> More about the cost of living increasing because software engineering salaries are rising around you…
We're already talking about very well-paid software engineers here. Appealing to a sense of sympathy over cost of living concerns of 1% earners and them trying to become 0.5% earners isn't exactly a strong argument here...
I use more (albeit cached) when centering a div.
Also worth noting simple horizontal centering of divs was never a problem, margin: auto was defined in CSS Level 1 in 1996 [1].
It was vertical centering that took a very long time to crack, which really became trivial with Flexbox which was first drafted in 2009[2] but became available unprefixed in browsers between 2012 and 2014 [3] about 13 years ago.
[1] https://www.w3.org/TR/REC-CSS1-961217
[2] https://www.w3.org/TR/2009/WD-css3-flexbox-20090723/
[3] https://caniuse.com/flexbox
Subnote: I'm not counting the display: table hacks.
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 think with sequential approach (translate -> make idiomatic) it is easier. However, I am not sure that monetary difference is going to be as stark as $165k vs 3 engineers/year. Especially, if you consider that no one knows that is what in the code at the end.
Sure, you can argue that now it doesn’t matter — agents and all that, but I am not so sure.
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).
You can use deterministic linting for `unsafe` usage, have agents target `unsafe`, etc. It's pretty easy. You can even run `miri` against the code and give that as a tool for LLM feedback. I've done this all before and it works fine.
> 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).
I'm unconvinced that this is true. How could you tell? You only know about the rust bugs because rust makes them grep'able/ trivial to verify, there's no way of knowing which bugs existed in zig that didn't translate. Regardless, the problem is now trivial to understand in Rust and start to target.
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).
That's a really strong motivation for the Rust port. It's literally impossible to take a path not leading to an unacceptable outcome because the Rust compiler fails the compile if code no longer marked "unsafe" is still actually unsafe, and the tests fail if the implementation is incorrect. The compiler actively helps to force the LLM to do things properly.
How odd. Lot of mental gymnastics going on there.
Do the rewrite that looks like we transpiled our Zig code to Rust. We can gradually refactor it to reduce unsafe usage and look more like idiomatic Rust after Bun v1.4 ships.
The original version of Bun was already a line-by-line (manual) port of esbuild from Go to Zig (also mentioned in this post), so the Zig code already wasn't "Zig-idiomatic" and apparently riddled with problems. That doesn't inspire much confidence in the LLM-translated Rust version tbh.
And yet Claude Code, which is the primary consumer, continues to chug away without any issue (that I, as a fairly heavy user, have encountered).
that is indeed a roughly accurate definition of what "unidiomatic" means
Eg. goto/jump, bare "except" statements in python, etc... In Rust, unsafe has its uses and is a first class language feature, but it certainly isn't idiomatic to use it to mimic access patterns from other languages (unless absolutely necessary).
The marketing value of this to Anthropic (if Anthropic even cares, this might just be the Bun team selling past the close) is to show that such a rewrite is possible and delivers engineering value. If exactly this project is $800K today, it'll be $200K and then $80K soon, so it's not so important to the story that it's cheap, just that a big "cool" rewrite is possible, and delivers velocity to the buisness.
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 likely just break some discrete part.
https://github.com/microsoft/typescript-go/discussions/411#d...
> But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping.
So basically the opposite of what you're saying.
This seems self-contradictory. If it's just a translation, doesn't that mean it remains fully compatible with that wider ecosystem? All the existing APIs retain identical behavior given the preexisting comprehensive test suite that had to go 100% green after all.
It's not.
Passing an existing test suite just moves the optimistic lower bound to incidental compatibility, it doesn't move it to intentional - "regard" implies you gave it thought.
Plus, it's not just about code: it's also about giving the ecosystem a migration path. Dumping 500k LOC on people and discontinuing development of the zig version effective immediately (there hasn't been a release since and the zig tree is only a reference - the build script is removed afaik) is the opposite of what TypeScript did. If you broke someone's N-API module because of a regression not caught by your suite they're now between a rock and a hard place.
The good news is that there's nobody there to notice. The bun userbase is miniscule* compared to TypeScript's.
* negligible? irrelevant? laughably small? I'm struggling to find an adjective that does the difference justice.
What kind of migration path beyond 0 regression do you think is needed? And if the latest Zig version is no longer available, how were at least 2 forks based on it submitted to HN? And what kind of release are you expecting when the team is working to fully migrate to the port (so far it's still marked canary)? If someone's using an untested (ie. very likely unpublished) API, well it sucks to be them but they should know the risks.
And again the self-contradictory argumentation. If the userbase is as miniscule as you imagine then your criticisms are essentially meaningless. No ecosystem worth giving a migration path and nobody's N-API module breaking because of a regression, right?
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?
I've heard stories of LLMs changing tests to get all the tests to pass instead of actually fixing code. So I'm not sure I trust it just because tests pass. I also think that tests do not and cannot check everything.
I also don't trust it just because it compiles in Rust. The Rust compiler does not check everything.
So at what point do projects like this cross from "untrusted" to "trusted"?
That's very easy to prevent. Don't let them edit the tests! Run the test suite against a reserved copy.
But the article talks about how so much code was written so fast. Seems to me that to create that much code that fast you have to have AI produce both the code and the tests.
So I am not sure in this project if the AI can edit the tests or not. I assume that because this is Anthropic the AI is doing as much as possible, which would include editing tests.
You can go and check if the AI edited the tests yourself: look at the git history of those files in the public Bun repository.
Otherwise all of us would just be able to build bun via a prompt.