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

31–40 of 109 posts

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

#31

Post by ventana »

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 discussed in the thread below, the most likely reason for that is that Express is pure JS with types from @types/express, so the TypeScript compiler bails on it. Reasonable, but still frustrating.

Overall, it seems like every time I decide to try a vibe coded compiler I get this feeling like when you see a plate with fruits on a table but, coming closer, see that they are fake plastic fruits. No, I cannot use it to build a native binary of my project without V8 as easy as shown on the front page. Maybe some other project, yes, but not a real one.

Unrelated: if a project is called Perry, should the icon be a platypus in a hat, you know?

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

#32

Post by jeswin »

> 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) {
    return animal.speak();
  }

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

#34

Post by avaer »

evil_buzzard wrote: post #4

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.

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

#35

Post by cornholio »

mirekrusin wrote: post #25
cornholio wrote: post #15

Earlier quoted context omitted.

Typescript is a dynamic language. Without changing the language, there is fundamentaly no way to resolve at compile time decisions that can be made only at runtime (ie, they are data driven). Monomorphization helps pin down (some) dynamic types but the fundamental problem remains.

Julia?

That's a JIT. Yes, you can do all sorts of optimizations in a JIT, because you do it at runtime using runtime information, and always keeping an escape hatch, so the static code bails when invoked with data it was not compiled to handle. This kind of hatch is used here with wrapping.

JIT is a technique to accelerate dynamic languages at runtime to near machine performance while keeping dynamic ergonomics; but it can't transcend the AOT / runtime wall.

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

#36

Post by avaer »

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…

It's not possible, it reduces to the halting problem, unless you start restricting the Javascript/Typescript you allow.

Otherwise the best you can do is be solid on common special cases. Which is what a modern (non-static) JS/TS runtime is.

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

#37

Post by satvikpendem »

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/

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

#38

Post by fooker »

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.

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

#39

Post by hypendev »

Perry definitely looks interesting, was just looking at getting one of these to include into my framework.

Would love to see more about it, or see more about the actual compiler docs.

While the UI framework part is neat, I prefer not to force everything into TS. Combining it means UI definitions and semantics get mixed into AST, making the unbundling of them a humongous task in itself.

Exactly the reason I built my own with pretty similar native UI semantics which supports Rust, Go, Kotlin and more (https://hypen.space) - would love to integrate Perry with it to compile TS apps directly into the runtime - but while the idea itself is great, looking at the documentation makes it hard to implement, and a lot of parts seem confusing.

Can I just use the compiler without the rest of the framework? What is the architecture? What are the limits?

After digging through the documentation, I'm unfortunately just more confused honestly. There are dozens of packages and slop markdown files such as `BUG_STRING_COMPARISON.md` and or `PERRY_UI_IMPLEMENTATION.md` which is an instruction file left for the LLM that just makes me trust the project less.

So while the idea is cool and the performance seems cool, the AI slop presentation would definitely need improvement. Adding a human touch would make it much, much better, as one could actually understand what they are dealing with.

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

#40

Post by jeswin »

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

Post reply on HN