perry VS proof-is-in-the-pudding

On other sites, like github and reddit. This exchange was funny though. He eventually gets called out by the other commenter to stop responding with an LLM: https://github.com/PerryTS/perry/issues/139#issuecomment-429...

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.

Compiler repo: https://github.com/PerryTS/perry

> strict, deterministic subset of TypeScript

I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list.

> Also, what's an "ambient surface" in this context?

I need to clean up the docs before v1. But the idea is that when JS gets transpiled into C# (or Rust, upcoming), JS globals and built-ins are invalid. The native "surface" is C#, meaning the string is .Net's string type and the methods that you expect on JS strings would be missing. But when you opt in to a surface, such as the "JS surface", the compiler applies surface defined translations such as substring becoming SubString, either directly or via a companion helper class. This allows you to write against standard JS and Node APIs, instead of relying on the stdlib/builtins of the target framework (currently only CLR).

For example, all the projects you see under this use the JS surface: https://github.com/tsoniclang/proof-is-in-the-pudding/tree/m...

You can see some examples here: https://github.com/tsoniclang/proof-is-in-the-pudding

And a hugo clone (native code of course) here: https://github.com/tsoniclang/tsumo

Actually TypeScript is an excellent language (in my view) for targeting native code. It reads cleaner than Java, C# and even golang in many cases - at least to me.

For example, JS/TS's file-path based imports are more intuitive; several languages do it via explicit namespaces when well-written code is already organized into directories. Of course, all of these design choices are subjective. In fact, disagreement with a few people in the C# user community is one of the reasons I started this project.

> At what point do JavaScript developers need to realise that this is all convoluted, and begin to use languages better suited for the job.

I'm curious to know what makes TS convoluted. Here's an example of multi-threading: https://github.com/tsoniclang/proof-is-in-the-pudding/blob/m...