Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perry Compiles TypeScript directly to executables using SWC and LLVM

perryts.com

Post reply on HN
Print view View original

41–50 of 109 posts

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

#41

Post by thayne »

jeswin wrote: 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…

> The hardest parts were numbers (TS has no ints or shorts)

The easy way to handle that would be to just treat "number" as 64-bit float, since that is semantically how Javascript defines them. But that can hurt performance.

Another option is to define your own integer types

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

#42

Post by satvikpendem »

jeswin wrote: post #40
satvikpendem wrote: post #37

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/

> 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

Interesting, seems to be a very roundabout way of doing it. Have you tried compiling the current TypeScript implementation which is still in TypeScript, as tsgo is for TS 7? If so, what were the results?

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

#43

Post by jeswin »

satvikpendem wrote: post #42
jeswin wrote: post #40

Earlier 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

Interesting, seems to be a very roundabout way of doing it. Have you tried compiling the current TypeScript implementation which is still in TypeScript, as tsgo is for TS 7? If so, what were the results?

Yep. The MS compiler written in TypeScript has a lot of dynamic behavior which tsonic cannot support. Those were not easy to port either, and tsgo seemed like a much easier target.

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

#44

Post by IshKebab »

jeswin wrote: post #40
satvikpendem wrote: post #37

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/

> 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?

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

#45

Post by jeswin »

thayne wrote: post #41
jeswin wrote: 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…

> The hardest parts were numbers (TS has no ints or shorts) The easy way to handle that would be to just treat "number" as 64-bit float, since that is semantically how Javascript defines them. But that can hurt performance. Another option is to define your own integer types

> Another option is to define your own integer types

This is what I did. Most int usage is inferred, but if they had to define it explicitly, I make them import { int } from "@tsonic/core/types.js";

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

#46

Post by Nathanba »

smasher164 wrote: post #13

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…

where exactly do you see comments by proggeramlug?

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

#47

Post by ventana »

jeswin wrote: post #32

> Traditional OOP runtimes use vtables for method resolution, adding a layer of indirection on every call. Perry resolves all method calls statically during compilation, turning interface method calls into direct jumps. What? How is this possible, even with something as simple as: interface Animal { speak(): string; } class Cat implements Animal {} class Dog implements Animal {} function makeSound(animal: Animal) { r…

I only grepped "vtable" in the repository so this might be not the relevant piece of code, but from the comment in [1] it seems they fallback to building a vtable if the static resolution is impossible.

[1]: https://github.com/PerryTS/perry/blob/39d5ba2e9db5adf7f7fc90...

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

#48

Post by Reubend »

jeswin wrote: 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 subset?

Also, what's an "ambient surface" in this context? Is that a compiler term I'm just not familiar with?

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

#49

Post by jeswin »

fooker wrote: post #38
jeswin wrote: post #32

> Traditional OOP runtimes use vtables for method resolution, adding a layer of indirection on every call. Perry resolves all method calls statically during compilation, turning interface method calls into direct jumps. What? How is this possible, even with something as simple as: interface Animal { speak(): string; } class Cat implements Animal {} class Dog implements Animal {} function makeSound(animal: Animal) { r…

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.

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

#50

Post by nl »

ventana wrote: post #31

I 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 / etc.) compile and run natively[1]

It's pretty standard for "no runtime" to mean nothing on the device you install the compiled target app.

I think iOS development still needs Ruby for Pod installation but no one says Swift apps need a Ruby runtime for example.

[1] https://docs.perryts.com/stdlib/http.html

Post reply on HN