> 0 ms Startup time
Is that true? It just goes right into the code with no initialization of any other libraries needed?
Perry Compiles TypeScript directly to executables using SWC and LLVM
51–60 of 109 posts
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#52Earlier quoted context omitted.
> such as this project which is converting tsgo to Rust If you'd like to follow, here's my attempt at converting tsgo to typescript (called tsts [1]). Admittedly there's AI involved, but it's a very mechanical job. Going from golang to ts is not a very difficult problem, the other way around would have been way harder. The plan is to then compile tsts to binary via tsonic. [1]: https://github.com/tsoniclang/tsts
Uhm... You're trying to port Typescript's Typescript-to-Go port back to Typescript? Am I missing something?
Yes. :) With the goal of compiling it to native code.
It's mostly a mechanical port. Hoping to do a Show HN maybe in a month.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#53I understand that implementing the TypeScript compiler is not the same thing as implementing all Node.js APIs, but still, advertising "no runtime" and then requiring JS runtime (and a full local Rust setup to compile it) for something as basic as an Express web server makes the "no runtime" claim look like a slight exaggeration. I'm not saying that it's bad, it's just that the website is too optimistic. Edit: as disc…
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 /…
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 * as express from 'express';
const app = express();
$ perry index.ts
Collecting modules...
JS module: express -> /private/tmp/ex/node_modules/express/index.js
Error: build pulled in `perry-jsruntime` (QuickJS-based eval-equivalent runtime) via the following file(s):
- /private/tmp/ex/node_modules/express/index.js [express]
`perry-jsruntime` is treated as a privileged dependency on par with adding a JIT to the binary — it re-introduces arbitrary runtime code execution and defeats Perry's structural advantage over Node. Refusing to link by default. (#499)
To enable, set `perry.allowJsRuntime: true` in the host package.json, or pass `--enable-js-runtime` on the CLI for a one-off build. (Falls under `--lockdown` deny set when that flag ships — see #496.)
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#54Earlier quoted context omitted.
You can just generate the 'vtable' as code :) switch (animal.type) case Cat: return cat_speak() case Dog: return dog_speak() The generated code has the functions resolved in compile time, there's no function pointer lookup in a table happening. I don't know if this is how this project does it, but this is the commonly used technique when you want to do this.
Hmm yeah good point. I didn't think of it. It might even be cheaper to do this when the list of possible types are closed and few. I am still inclined to believe AI just made up the documentation though, because this has its own tradeoffs.
> might even be cheaper to do this
Oh yeah, very often. Especially if it's a loop and resolves the same way very often.
Modern CPUs just blaze through code like this, after three decades optimizing for object oriented and dynamic languages.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#55Earlier quoted context omitted.
Trust of a project long term always was and continues to be of concern when choosing a critical dependency . The concern basically boils down to how large and serious is the team and what if they abandon the project in few weeks or months . These were always the risks, many here have been burned by betting years of their career building against promising but what turned out to be weak projects OP is alluding to the f…
I think the primary value of a project like this is the demonstration that this is possible and a proof that it does not incur some unknown tradeoff you'll discover after spending resources doing it. IMO the maintenance story is more or less solved if you can keep AI agents refactoring and improving it in a loop. > However not everyone has access to unlimited tokens Apologies. I did not consider this when writing my…
> IMO the maintenance story is more or less solved if you can keep AI agents refactoring and improving it in a loop.
That’s a weak argument, though, if the future of AI is totally unreliable when it comes to cost and quality. Right now I definitely wouldn’t want to depend on being able to infinitely access AI tools for such an important part of the toolchain.
Aside from that it’s just not attractive to trust a project made by one person.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#56Earlier 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 /…
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.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#57First 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…
Does tsonic have debugging support of any kind and how fast is the compiler?
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#58the 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?
They probably are, given that's how Flutter and other Rust GUI frameworks work too.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#59the 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?
Its documentation mentions a garbage collector.
https://docs.perryts.com/language/supported-features.html#ga...
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#60I understand that implementing the TypeScript compiler is not the same thing as implementing all Node.js APIs, but still, advertising "no runtime" and then requiring JS runtime (and a full local Rust setup to compile it) for something as basic as an Express web server makes the "no runtime" claim look like a slight exaggeration. I'm not saying that it's bad, it's just that the website is too optimistic. Edit: as disc…
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.