Live data from Hacker News

Perry Compiles TypeScript directly to executables using SWC and LLVM

perryts.com

61–70 of 109 posts

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#61
post #5

Fascinating. I've written cross platform (WASM, iOS, Android) libraries with Rust before and had a good time but Rust can be a pain too. Cross-platform Typescript is a really interesting proposition. That said, the more I think about it the more dubious I am. The site boasts no runtime dependencies but clearly it’s going to need things like a garbage collector, you can’t just magic that requirement away. At a certain…

how do one tell when text is ai generated - honest question. What are the tell tale signs?

vibrant colours that don't match

X. Y. SUPER Z. heading

X. Y. SUPER Z. in subheading

excessive purple and gradients

--> arrows

cards, cards, cards, cards

doesn't just X, emdash, it [SUPER Y]

more cards

ridiculous awful contrast in copy that makes things unreadable (grey on black etc)

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#62

A very interesting project because I always thought TypeScript or at least some subset of it should be natively compiled. It looks like others had a similar idea too, adding a "sound mode" to TypeScript, such as this project which is converting tsgo to Rust, also with LLMs. https://news.ycombinator.com/item?id=48189156#48189573 https://tsz.dev/

It already exists for years, it is part of Microsoft's MakeCode efforts for kids.

https://makecode.com/language

https://www.microsoft.com/en-us/research/publication/static-...

Much saner than a vibe coded compiler.

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#63
post #17

I'm not against AI usage but the website, documentation, and even the comments the creator (proggeramlug) makes in response to questions are all very clearly AI-generated. Also, as someone else noticed, the pacing of the commits is eerily fast. That combined with the level of functionality makes me dubious how much accountability the creators have over the implementation. Like you really built a backend that lowers t…

This is how software development works now. We have to live with it. The models are good enough that this works. You can keep disagreeing for a while, but know that almost all the code in the industry is written like this now.

Not at all, I can assert that the Spring code on my current project is classical programming.

In many places AI tools aren't even allowed to touch customer repos.

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#64
post #34

the claim of "no runtime" is a bit dubious... you're telling me that you're statically linking a full, modern UI library into every app?

A runtime is needed for GC, unless you're fundamentally changing Javascript. Even golang has a runtime.

Even C has one, regardless of how tiny it happens to be, or the possibility of freestanding deployment.

In compiler speak, a runtime provides all infrastructure required by the language for program startup, shutdown, infrastructure for the standard library execution.

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#65
post #48
post #26

First of all, congrats. The website doesn't explain how it works in a lot of detail. I am the author of tsonic [1], a TS compiler that produces binaries via Clr NativeAOT (on Linux/Mac). The hardest parts were numbers (TS has no ints or shorts), Generics, and TS Utility Types. I've been on it for the last 6 months (almost every day); getting to near complete TS compatibility is a very long journey because of its expr…

Hey there, I'm going to check out your project because the comments here have me a little worried that OP's project might have some quality issues. Two things I found a little confusing from the docs though: I couldn't easily find a page describing what it can't do yet. I saw that it only works with a "strict, deterministic subset of TypeScript", but is there a page showing what's included and not included in that su…

> 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, and include it along with the large docs cleanup planned before v1.

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

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 CLR). And you get the JS "stdlib" - console, JSON, Date, Map, Set etc.

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

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#66
I'm confused by the (frankly bad) documentation. It says that for pure js dependencies we need to use the v8 flag to bring in the runtime (which is undesirable), but what is the practical difference between a js file and the same file with .ts extension and explicit *any* type in every signature? Does this mean that we have to be very careful how we write our typescript to avoid v8 (and if yes, how? I couldn't find that on the site) or does it mean that we can get away with transpiling everything to ts with loose typing? I suspect it's the first, in which case it's literally the most important information that anyone using Perry needs to know, and it should be one of the first things mentioned in their AI-vibed page.

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#68
post #60
post #50

Earlier quoted context omitted.

This seems either wrong or very uncharitable. > Perry exposes a faithful subset of Node.js’s stdlib HTTP server modules on top of hyper + rustls + tokio-tungstenite. The whole shape — handler signature, IncomingMessage / ServerResponse properties + methods, TLS opts, ALPN-negotiated HTTP/2, WebSocket upgrade dispatch — works unmodified, so unmodified Node servers (Express / Koa / Polka / hono via @hono/node-server /…

> It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app. Only by layman that don't understand compilers.

The tone here is a bit rude but I'm still curious: what does no runtime mean to you?

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#69
Browsing through the repo, I noticed this, and wondered if that isn't a recipe for disaster (code is condensed to showcase my concern)?

  app.get('/api/auth/callback', async (request: any, reply: any) => {
    const params: any = request.query || {};
    const code = params.code || '';
    const state = params.state || '';
    // Exchange code for token via curl
    const tokenResult = curlExec(
      'curl -s -X POST "https://github.com/login/oauth/access_token" -H "Accept: application/json" -d "client_id=' + GITHUB_CLIENT_ID + '&client_secret=' + GITHUB_CLIENT_SECRET + '&code=' + code + '"'
    );
Shell injection?

Re: Perry Compiles TypeScript directly to executables using SWC and LLVM

#70
post #56
post #53

Earlier quoted context omitted.

Well, I did indeed spend some time playing with it before writing my comment. I first tried to compile the TypeScript project I'm working on, and it happens to be an Express server. After some minor unrelated fixes required (Perry does not understand importing "fs/promises", so I fixed it to import "fs" and then taking .promises) it said it needs JS runtime, and the smallest repro I found was $ cat index.ts import *…

Fair, but might have been worth including that in your initial comment because the docs don't mention that at all.

I got the impression from the first comment that it was speaking from experience not the docs
Post reply on HN