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

71–80 of 109 posts

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

#71

Post by mohsen1 »

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/

Just a clarification that tsz is not a port of tsgo or tsc. It's an entirely different architecture. Inspired by Chalk and Salsa it does all of the type computations to a solver crate that does not know about the AST. This allows me to do very fast type equity and assignability computations without carrying the weight of AST nodes while walking the type graph etc.

It's already showing results that is nearly 3x faster than tsgo. For multi-file large projects I have some ideas to implement to make it faster there too.

Once tsz is fast and stable I'll shift focus on making sound mode a reality.

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

#73

Post by mohsen1 »

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…

I am taking this attitude to an extreme with tsz. I don't want to announce to the world that tsz is ready until I tested it really really well.

Currently tsz passes nearly 100% of TypeScript tests but that is not enough. I want it to be able to type check complex things like type-challenges solutions or complex utility type packages. I'm stress testing it with a repo with 1.5 million lines of code.

I'm constantly assigning AI agents tasks to find bugs in tsz and open issues.

I'll say this is "alpha" when it can do all those things plus matching tsc exactly in thousands of open source projects where tsc reported type errors. It's easy to find CI runs that tsc reported errors. I'll build a database of all the cases I've verified tsz with and will publish those. Hoping that can give folks confidence that tsz is robust

For now, tsz is just a work in progress.

https://tsz.dev

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

#74

Post by pjmlp »

lkirkwood wrote: post #68
pjmlp wrote: post #60

Earlier quoted context omitted.

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

It is my tone, GenX, no minced words.

The infrastructure required to support a programming language, startup and shutdown boilerplate, all the required functionality to support standard library features including integration points between language semantics and support code.

Stuff like what code runs before and after main(), trap handlers for floating point arithmetic, handling of thread local storage, bind language heap handling primitives to library code, traps for handling stack overflow errors,....

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

#75

Post by tacone »

Just spent an hour trying to make it work (including re-compiling) with the jsruntime.

`Error: JavaScript modules found but libperry_jsruntime.a not found. Build it with: cargo build --release -p perry-jsruntime`

Turns out jsruntime was removed one week ago, but the error messages probably not have been updated as they should.

https://github.com/PerryTS/perry/commit/848339fa4ee4b00a53f5...

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

#76

Post by incrudible »

rzmmm wrote: post #21
fooker wrote: post #17

Earlier quoted context omitted.

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.

I have used AI agents extensively for coding and my experience is that it's fine for prototypes, but in large projects like this there is risk that the codebase becomes unmaintainable.

In large projects there is always a risk, if not an inevitability, that a code base becomes unmaintanable by some definition. AI surfaces this faster, but also AI lowers the cost of testing and refactoring. AI gives a linear multiplier in producing solutions, but complexity gives a quadratic increase in problems. The art of producing software has always been in choosing what not to do.

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

#77

Post by lenkite »

Why are all vibe-coded web-site cards so stupidly identical ? I have seen dozens of these and whenever they use cards, there is an icon taking valuable space by itself followed by a header. That is ridiculous design and any designer/CSS developer would point that out. So why do LLMs emit this ?

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

#78

Post by nurettin »

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…

To be fair, nowhere on the frontpage does it say it can build libraries that depend on node. It seems like you are just waiting in the bushes to dis AI assisted coding.

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

#79

Post by tomcam »

mohsen1 wrote: post #73
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…

I am taking this attitude to an extreme with tsz. I don't want to announce to the world that tsz is ready until I tested it really really well. Currently tsz passes nearly 100% of TypeScript tests but that is not enough. I want it to be able to type check complex things like type-challenges solutions or complex utility type packages. I'm stress testing it with a repo with 1.5 million lines of code. I'm constantly ass…

This looks exciting.

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

#80

Post by wren6991 »

pjmlp wrote: post #74
lkirkwood wrote: post #68

Earlier quoted context omitted.

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

It is my tone, GenX, no minced words. The infrastructure required to support a programming language, startup and shutdown boilerplate, all the required functionality to support standard library features including integration points between language semantics and support code. Stuff like what code runs before and after main(), trap handlers for floating point arithmetic, handling of thread local storage, bind language…

Right, runtime is so broad that it's hard to say something has "no runtime". libgcc + your choice of crt0 is a C runtime, and the JVM is a Java runtime. That's a huge spectrum.

It's worth being charitable in your interpretation though and recognising "no runtime" probably refers to JVM-shaped or Node-shaped things, not libgcc+crt0-shaped things.

Post reply on HN