IMHO, this is an actual good use of what sounds like a person guiding a model to do a mass conversion. Although, I wish the porting docs were a little wordsmithed by a human, the AI generated text style is grating.
The stakes are low, it’s mostly for fun and you can iterate on it. Compare this with Bun which was just like, “hey we converted everything to Bun to Rust from Zig, of course it works, what could possibly go wrong, I’ll totally write up a blogpost (that still doesn’t exist) explaining what we did, you can put this into your production environment soon!”
I don't really get the Bun thing. Bun is running Claude Code which is probably the single most actively used development app there is. You say this was a bad use of LLMs, but it's been in production for a while and I haven't heard of any evidence that Claude Code has increased a significantly larger quantity of errors, segfaults, etc, than before.
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.
"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.
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.
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.
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.
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.
I agree that the Bun rewrite is much more reasonable than knee-jerk reactions imply, however:
- I don't think Claude Code is using the Rust version yet in their official build
- Claude Code is not a particularly complicated piece of software from an engineering perspective (nor it's particularly well-engineered, at least at the moment).
So in my book "it runs Claude Code" would be pretty weak evidence that the rewrite is going to be successful (the tests they've done are much better evidence, but that's a topic for another time).
Now, Bun 1.4 doesn't seem to officially exist on https://bun.com/blog or https://github.com/oven-sh/bun/releases, so I can't be 100% sure this is the Rust version. However, I have to do some patching of the Claude Code binary to get it to run on my OS, and version 2.1.181 coincided with some changes that make suspect it's using Rust now.
I agree Claude Code is seemingly (currently) not very well-engineered but I think you may be moderately underestimating how complicated it is/necessarily has to be.
Huh... it looks to me like bun has yet to cut a release post Zig->Rust port (the latest one on github is still on a branch that says it's written in zig in the readme). I assume that nothing is using the rust version yet...
Which also cuts against the complaints about "of course it works [...] you can put this into your production environment soon!" since they don't seem to be asserting either of those things.
The real problem is they explained nothing and just caused a lot of mistrust. The lead developer at Bun working on this project does post here from time to time and I have never seen him answer any of this. I admire his enthusiasm, but this was badly handled mostly from Bun’s side which lead to a bunch of dogpiling.
When someone on another social media platform commented expressed some concern, his response was to ask him what the explicit bug he was talking about was and that he would generate a fix. That sound you hear is the woosh as the point flies by. And in general, this just feels like a consistent problem with Bun.
I have yet to hear any evidence that the Rust rewrite was harmful. I have no emotional investment in Bun (which I'd never heard of before the rewrite), or Zig (which I also didn't know about), or Rust (which I think is neat and that's about it), so I'm about as unbiased as you can get and from what I saw the conversion was done well, and I haven't heard of massive bugs resulting from the rewrite.
It is probably fine, it is kind of a best case scenario: porting a good code base with lots of unit tests, all hand-written. Not much can go wrong here as the LLM is kept in check by the original code, the tests, and the fact that the topic (a JS engine) is well documented.
The problem is what comes next. They now have code that they don't understand, and they are likely to work on it with AI in the future, but the new features they may introduce later will not have the luxury of hand-written tests and a reference code. So, unless they undertake the massive effort needed to fully understand the Rust code and deal with all these "unsafe", quality is very likely to go down, Microslop style.
> which is probably the single most actively used development app there is
Seems doubtful, I'd put money on it being something like Visual Studio or Visual Studio Code. Maybe CC could claim the (odious) title of most actively used vibe-coded development app, though.
I have a port of BuildGDX in the project backlog that was basically just throwing Claude at it to go from Java to .NET. The only thing it really got hung up on was Java's byte being signed.
What I ended up with was a port of Duke 3D that uses half the allocated RAM as DukeGDX.
This is another "AI-ism" I noticed, mostly in coding agents - they seem to be very fond of making up new "compound nouns" (and occasionally verbs) to sum up relatively complex and specific concepts into single noun phrases. I wasn't sure if it's to save tokens or if the AI uses this to get a concise "identifier" for a concept that it can refer back to later, but I found it very noticeable.
I find the resulting sentences hard to read, though it does get better if you're aware of that tendency and make a conscious effort to parse the noun phrases. But I guess since it's just intermediate output from coding agents and not text for essays or blog posts, it's fine.
It's a thing in some Germanic languages. Instinct is to merge nouns into word, e.g. 'lawnchair', but that gives you a red squiggly line, but 'lawn chair' also looks wrong, so 'lawn-chair' is the middle ground.
> English word origins are a fascinating rabbit hole.
My favourite example of which is Northern Ireland's Orange Order.
The colour is orange, because that was the Royal colour of the family of the monarch it was named after, William of Orange, who was Dutch, titled after the principality of Orange which is named after the city of Orange which is French which got its name from the Celtic word for forehead or temple.
The colour is named after the fruit, the fruit's name is a corruption "a norange" -> "an orange", which goes back to naranja which goes to Arabic which goes to Classical Persian which goes to Sanskrit.
Meanwhile, the dutch word for the fruit is sinaasappel, Chinese apple, compare with the English word "mandarin" used for many different Chinese things.
Yes! It's infuriating. I've tried prohibiting them in my AGENTS.md but it's not 100% effective.
--- AGENTS.md ---
## Plain words, not jargon
Don't use jargon-as-shorthand. Say what you actually mean.
- Don't say "load-bearing assumptions". Say "the assumptions the xyz depends on".
- Don't say "cross-service". Name both services, e.g. "whether the X
service can derive duration without calling the Y service". "Cross-X" is
confusing because it hides which things are involved.
- Don't deliver verdicts as abstract noun-phrases like "Cross-RCA
double-counting is unfounded". Say it plainly: "I checked whether the same
root cause gets counted twice across RCA runs, and it doesn't."
## No earth-shattering declarations
Don't hype findings. Skip "a critical finding changes everything", "now I have
the full picture", "this changes the game", etc. Just state what you found
plainly. Most findings are ordinary; report them that way.
## Don't reflexively hedge a "yes"
When the answer is yes, say yes. Don't soften every positive answer with a
caveat: it erodes confidence in the "yes". Only add a caveat when there's a
genuine, specific uncertainty worth flagging.
On another note, I find AI instructions like this (e.g. "Don't hype findings. Skip "a critical finding changes everything",...") more harm than good in my own uses. It changes behavior in subtle ways that makes it less predictable to me. I'd rather it has its own AI-isms and quirks, that I've fully gotten used to, and I know what to expect. I know when it says certain things, in certain ways, that's what I think it means. Quirks and AI-isms don't annoy me, I get used to how it states things.
Lol! Good point. I did use Claude to write the rule, and it ironically wrote the exact thing I asked it to avoid. I agree that it might be best to use the model as-is, to get the intended experience.
Also I find it interesting to learn the jargon. It basically compacts information in fewer words, although more complex words. But when you are familiar with the jargon, you can unpack the sentences in your mind. And like that, you need less text to read and write prompts. So less reading, writing, and tokens!
I thought it was just Opus 4.7 and 4.8 that did this. Do other models do this too?
Anyway: in my case Opus absolutely did not follow a similar instruction in the CLAUDE.md file. (But then again: it hardly followed _any_ CLAUDE.md instruction properly)
It's stupid, but have you tried telling it to follow it? "Make sure to follow the guidelines from AGENTS/CLAUDE.md" etc, seems to (sadly) make some difference in most harnesses and models.
For me, Opus 4.8's thinking traces for the chatbot will sometimes willingly ignore instructions, saying something along the lines of "I've noticed an instruction in the system instructions that states I shouldn't do this, but if I don't do this, I'll not provide the answer the user is looking for. I will ignore that instruction."
In all my CLAUDE.md and AGENTS.md files I have a line to fix pre-existing issues. I don’t know what it is but every agent I’ve tried through Claude code (including deepseek and GLM) will actively try to avoid fixing pre-existing issues. I even added hooks to Claude and git to try to get them fixed. If I leave a bailout for myself agents will find it sit and ask if it can push with no-verify or an environment variable in the case of Claude hooks instead of trying to fix an issue it didn’t cause.
Yeah, I wonder if part of the reasoning is built around those phrases, and therefore it can't get rid of them easily.
> "now I have the full picture"
I always interpreted that phrase as a sort of marker to delimit the phase in which it explores the codebase and gathers information from the phase in which it implements the changes.
Not sure if it's still done, but I think some months ago there was discussion that some of the phrases are injected by the inference loop to "steer" the model - e.g. "But wait" if a thought block was too short etc. Obviously such phrases couldn't be influenced by the prompt.
"The model refuses to follow my specific word detail prompts" and "The model refuses to perform hacking attempts" are on the same side of the model refusing to do something baked into it though.
I’m (sorry for the lack of humbleness) a very fluent non-native speaker and writer, and this is by far my biggest challenge with Claude. It stitches together 2-4 advanced concepts into one or two words and I always have to ask it to “unpack”.
I don’t think it’s easy on native speakers when it happens, but it’s even harder when you’re not.
Few ever cared. Find one non-pedant who would object to the personification that follows:
"The evening settled over the city, drawing the light out of the streets one corner at a time. Windows blinked awake with lamplight, and the wind moved through the alleys restlessly, leaves brushing against walls before gathering themselves along the pavement. In the distance, the river kept its steady argument with the stone embankments. When the night pressed in, the weather became increasingly angry, until it was a raging storm."
In the affective sense, evenings don't settle, and street lights are not drawn out, windows don't blink, and wind isn't restless. Weather can neither be angry, nor rage.
But such personification is a natural part of how the English speak.
> Built on EA's GPL v3 source release via fbraz3/GeneralsX (which did the heavy lifting of the macOS/Linux port — this fork adds the iOS/iPadOS port and a set of engine fixes).
Right? All Fable did was a ported an already cross platform project to ios. Does not look like any sort of heavy lifting there, opus 4.6 would do just fine
I wanna know if these techniques would be useful for Emperor: Battle for Dune (2001). It's the first 3D RTS by Westwood Studios, predating C&C Generals by just a couple years. It's popularity was hampered by intellectual property disputes and a introduction of a new faction that diverged from the book series lore. The gameplay, soundtrack, and campaign missions were awesome.
Emperor was a great game. My only real complaint was the five sub-factions seemed to be imbalanced. I’d like to revisit to see if the was missing something.
no way fable did this. It would have stopped after the words "command and conquer" and nerfed you to opus (while also landing you on some nsa watch list)
I’ve been using it to use Ghidra to do reverse engineering for modding Zelda: Tears of the Kingdom. Pre-ban it would flag immediately, post-ban it _rarely_ flagged anything and when it did I realized I could just make a memory telling it to convert reverse engineering speech into game development speech, not mentioning pointers, memory, addresses and decompiling. Then the flags mostly went away.
You can sidestep flags by just compacting and then changing the model back at any rate.
I spent countless hours on this game as a kid and as I got older I found that trying to go back and play the game got more and more difficult as the technology scaled beyond the platform it was originally intended for.
A great use for what AI can help with, especially in the hands of dedicated fans. Maybe I will find some time to try and experiment with custom maps or units, the modding scene of C&C Generals was always pretty lively.
Am I reading that right? It makes API calls that go through 5 different layers before actually getting rendered? That's kind of crazy. I'm surprised it works, although I guess the underlying libraries are solid enough that it shouldn't be unexpected.
Apple never released a driver that supports Vulkan out of the box, therefore MoltenVK was born, which translates Vulkan IR to Metal source then recompiles to Metal shaders.
This was the pipeline in Proton for macOS (I'm not sure if it's still is the case, been quite a while since I checked).
For that to be click bait it implies people wouldn’t have clicked on it if any other model were used. IMO the more interesting fact is they ported a game over to iOS.
I've been doing something similar for some of my favourite older games. But the "byte for byte" claim has me worried. Isn't simply decompiling the sourcecode from the binary and releasing that problematic?
It's not the "clean room" approach and companies could still claim it violates some kind of copyright and get it taken down.
That's my understanding. Decompilation is legally protected in the US, and you can do a reimplementation based on a decompilation. Sony v connectix is aiui the precedent.
Theoretically you could clean room by having different agents/models/context windows to do both decompilation and reimplementation. This is untested in court afaik and I don't think anyone wants to spend money to find out.
There was a non-clean room reimplementation of gta3 a few years ago. The gta publisher DMCAd and of course the fans who did it didn't have any money to fight in court (and probably couldn't find anyone who would take a big complicated case on such bad facts pro bono). https://www.gamingonlinux.com/2021/02/take-two-interactive-h...
And maybe it wasn't even Fable, they might have downgraded to Opus.
This is the kind of frequent misinformation that makes me skeptical of Anthropic LLM claims. Whenever I compare them to GPT 5.5 on my web dev workflows, they seem to trade blows, even Fable, which I started testing since it was re-enabled.
Also I bet any decent LLM could have done such port. Think GLM 5.2 or similar which would probably work better because it doesn't constantly try to guess if I'm a terrorist trying to hack goverments or develop some biological weapon.
People just don't have the resources to compare LLMs and imply whatever they used is the best thing ever and unlocked some new workflow.
This project is a fork and all it does is add iOS support. Commits by the repo fork owner begin 19 hours ago, so very plausible those are done with Fable. But I agree it's very unclear to me if adding iOS support was some task only Fable could accomplish over prior models.
Red alert 2 was released in 2000, which means it was developed probably in 1998->1999.
Life was different back then. Source control systems were a LOT worse (this is CVS era for open source development). We certainly weren't in the current era where everyone wants to play these old games on their phones now.
What almost certainly happened is all copies of the source were simply lost. They may have sat on someone's hard drive, a team server hard drive, or somewhere else. It's possible they didn't have more than a few copies while development was ongoing.
Everything will be lost unless it's somebody's job to preserve it. It's pretty common to close game studios or lay off the entire development team while simultaneously scolding them about "stealing" IP so the predictable result is the code being lost.
I was bitching here the other day about GTA VI being locked down so I can't pass it on like a favorite book. But maybe if I just archive the whole package, a not-so-distant-future-ai will be able to rehydrate it onto any handy future platform at low cost.
Assuming nothing like DRM goes out of its way to prevent it, I’d be willing to bet significant money that by the time GTA6 is retro enough to require porting to “modern” platforms, precisely that sort of porting will not only be possible, it’ll be so commonplace that it won’t even merit an HN post when it happens.
reasonably it works quite close to the lingo, but this is way difficult, and not just from being rusty. steve had most things triggered on the animation frame, which opus hasnt quite figured out by looking at the code and pulling stuff out of the .dir
i do remember that playing at double scale was a lot harder in general, but theres a really clear cooldown missing between attackes
One big caveat with iPad and mobile, though, is battery usage. I strongly suspect that power consumption is the reason that a number of games made it to Mac, but not iPad.
Well interface on mobile devices vs traditional computers is a bit different. Game devs can’t even have consistent controller support. Supporting touch is almost never worth it.
> Long sessions on iPad can be killed by iOS for memory (~3 GB+ resident); the app exits to the home screen with no dialog. Session logs (current + previous) are in the Files app under the game's folder. Under investigation.
Wait. It's a port from a game from 2003. I don't think PC had 4 GB of memory back then (unless my memory is fuzzy, ah!): I mean, maybe some had that, but not the majority. I doubt the requirements for the original C&C Generals were 4 GB of memory.
OK, I just checked on a box of C&C Generals on eBay: requirement 128 MB of RAM (I know I could have asked a LLM, but checking a picture of an actual box is kinda fun).
I understand the need for a bit more graphics etc. but that's still a big jump: if the reqs were 128 MB or RAM for the PC, the game wasn't using that.
So we're talking something like a 32x inflation in RAM usage during the port (unless I didn't understand the caveat).
Why can't a game requiring 128 MB in 2003 run on machine 20 years more recent without using all the RAM?
Is there a plausible reason or are we to consider that when porting using Fable, we can expect the RAM usage of a program to go up by 32x?
EDIT: the original game has more asset than I would have guessed, skimming through the port's docs I found this:
> the game requires .big archive files (INIZH.big, MapsZH.big, etc.) totaling 4-5 GB. These files cannot be committed to repository due to copyright (EA Games property).
4 / 5 GB is not nothing. I wonder if the memory issue could be related to the way these are loaded?
EA released the Generals source under GPL v3, the GeneralsX project got it running on macOS/Linux, and I've taken it the rest of the way: native iOS and iPadOS builds of Zero Hour, plus Apple Silicon macOS.
What works (all verified on a real iPad and iPhone):
Campaign, Skirmish, and Generals Challenge: full missions, objectives, cutscenes, saves
All audio: music, unit voices, EVA announcements, Challenge taunts, briefing FMVs
Touch controls built for RTS: tap select, drag a selection box, long-press deselect, two-finger camera pan, pinch zoom
Self-contained install: game data ships inside the app bundle
It's the real engine: unmodified game logic compiled for ARM64, rendering DirectX 8 → DXVK → Vulkan → MoltenVK → Metal. Not emulation, not streaming.
No game assets are included or distributed. You need your own copy (Steam sells Zero Hour) and a script pulls the data from your own account. Code is GPL v3.
Building: macOS is about four commands; iPhone/iPad needs Xcode and a free Apple developer account since you sideload your own build. Known issues (long-session memory on iPad, a rare backgrounding crash) are documented in the README.
Credit: fbraz3/GeneralsX did the heavy macOS/Linux lifting, TheSuperHackers keep the community codebase alive, and EA did a genuinely good thing releasing the source. The engine fixes I found are heading upstream so every platform benefits.
(And of course, not affiliated with or endorsed by EA, and sorry China had to deal with all of those particle cannons in that demo video)
You take credit for porting it to "Apple Silicon" macOS, both here and in the title, but that already seems to work upstream? On a quick look I didn't see any commit message of yours addressing macOS rather than iOS. What exactly did you add there?
When someone ported pylint to rust this place was full of ‘who will maintain this’ and met with blank stares when the answer was ‘what do you mean’ or ‘it’ll maintain itself’.
Good job. It was inevitable, but still someone had to, please excuse me, say the words.
Given the game is stable and the changes would be at the integration points, and Fable was able to do the direct integration, why would the answer not be “it’ll maintain itself” at some abstract level. The decision to maintain open source is up to the maintainers and I think the answer is “no one” 99.99% of the time, but I’ll wager if someone is willing to spend the tokens on it, a CI reintegration agent would do just fine in keeping it working as the underlying dependencies have required changes (which would really be only major changes in apple apis that aren’t backwards compatible.”
Pylint is different because it’s working against a necessarily dynamic wavefront that it has to keep parity with as it advances. All python changes, ecosystem adaptations, etc - and maintaining that with an AI harness in CI would never work. It would require a concerted effort and thought along the way.
So it’s sort of a different beast all together. In fact I think this is a great demonstration of using AI to resurrect technology built for X to work with Y, where X is dead and Y is current. Automating this feels like a net positive and because the original software is “finished” there isn’t decision making and strategy required.
These LLMs are remarkable. I used Opus to revive for myself abandoned software and bring it up to date with the latest versions of the frameworks so I could add some features. And there's other software which I vendor and merge in upstream changes and self-manage. This would have been a near-impossibility in the past.
"Who will maintain this?" appears to be "Me with an agent". And it's great.
The stakes are low, it’s mostly for fun and you can iterate on it. Compare this with Bun which was just like, “hey we converted everything to Bun to Rust from Zig, of course it works, what could possibly go wrong, I’ll totally write up a blogpost (that still doesn’t exist) explaining what we did, you can put this into your production environment soon!”
reply