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.
reply