Now, to tell you the truth, for a lot of tickets AI does generate legit the better answers than me. And my time is quite limited.
That said, I will always stand behind my posts, AI-assisted or not.
Now the thread you specifically point at here is ironic in many ways. The other guy says "and claude won't tell you that", while in fact Claude said (in my response) the exact thing he claimed Claude would not be able to do. Anyways, the technical merrits of the conversation are certainly worthwhile and important.
thanks for bringing up the concern. I am proggeramlug (or amlug, either way), Ralph, founder of perry.
Yes, Perry is heavily AI-assisted - similar to the Bun to Rust port is too. Your concern is real and I don't claim to have all the answers for that.
I do know that AI is much better at finding bugs when it comes to compilers than most humans will ever be. Decoding bytecode and knowing what it should be is nothing humans are good at - AI does it trivially.
So yes, lots of AI, but this is not a "vibe-coded" slop project either. I have decades of experience in programming (native) and so I'm quite confident that this will work out well - but I totally see your skepticism.
(I'm the founder of Perry) thanks for giving it a try and let me be upfront with you: Compiling express has been one of the hardest challenges for Perry. I'm 99% sure it still does not work out of the box just yet - which is why we pivoted to fastify more than express.
That said, the last few days we made great progress to get Perry to compile packages "lik" Express (lot's of dynamic imports) much better.
I'll retry this once our current batch of Nodejs parity issues are resolved.
Just to be clear though: No v8 runtime, we actually took out the v8 engine we had optionally included thus far because the benefits no longer outweight the disadvantages.
If you want to tag along the progres follow me on X (@proggeramlug), that's where I share the most up to date progress on Perry.
Also, it is definetely a goal to compile apps that use Express and that will happen - not commiting to a timeline but just in the last few days we got so much closer.
thanks for your comment. I'm Ralph, the founder of Perry (though at this point we are quite a few core contributors + maintainers).
You are right to be skeptical and yes, numbers are the hardest. In fact we started adding some native numbers to make things easier (i64, i32 etc.), types that are not natively available in Javascript/Typescript but make it much easier for the compiler. And they'll internally work as numbers for any other runtime.
The docs I must admit are not quite up to date. We have been pushing hard for Nodejs parity the last few dayys/weeks and are making great progress, however the docs and the site have not been updated in the same time just yet, so apologies for that.
Also, just as a fun fact: I noticed a spike in traffic and found this threat, so happy to take any requests but I'm not the OG of this threat haha.
I'm the "AI cringe guy" if you want to call it that. Yet I am still waiting for someone to produce typescript that compiles wrongly.
I have limited time, and the little feedback that guy provided turned out to be perfectly well answered by AI. So sorry, but either you actually criticize something actionable to just shut up, but I don't have the time to debate this if the simple few lines don't get answered.
We're building a TypeScript-to-native compiler (Perry) and wanted to evaluate whether Claude Code's codebase is something we could realistically compile. Since it's closed source, that meant reconstruction. Claude dispatched 7 subagents — two refused to extract the system prompt on ethical grounds, the parent called them "shy" and did it anyway. 12,093 lines reconstructed, 0 systems penetrated. Key technical findings: internal codename Tengu with 654+ feature flags, sandbox-exec with dynamically generated SBPL policies, bubblewrap on Linux, three-tier context compaction, deferred tool loading via ToolSearch, and smart-quote normalization for LLM-generated curly quotes. Happy to answer questions.
Hey HN — I've been building Perry, a compiler that takes TypeScript and emits native binaries. No V8, no runtime, no Electron. It maps to platform-native UI widgets: AppKit on macOS, UIKit on iOS, Android Views on Android, GTK4 on Linux, Win32 on Windows.
Pry is the first real app built with it — a JSON viewer, deliberately small.
It's in the iOS/macOS App Store and Google Play right now. Linux build works, Windows is waiting on code signing.
The compiler itself is written in Rust. It handles TypeScript parsing, type checking, and lowers to native code. The UI bindings aren't a wrapper library — the compiler generates the actual platform API calls.
This is a building-in-public thing. Pry is the proof-of-concept. The bigger goal is a full IDE. Happy to answer questions about the compiler architecture, the app store submission process, or anything else.