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…
Perry Compiles TypeScript directly to executables using SWC and LLVM
91–100 of 109 posts
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#92Earlier quoted context omitted.
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.
There's practically no difference for the overwhelming majority of software these days. Most people aren't working on embedded systems or operating systems.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#93I'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
#94First 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…
thanks for your comment. I'm Ralph, the founder of Perry (though at this point we are quite a few core contributors + maintainers).
You are right to be skeptical and yes, numbers are the hardest. In fact we started adding some native numbers to make things easier (i64, i32 etc.), types that are not natively available in Javascript/Typescript but make it much easier for the compiler. And they'll internally work as numbers for any other runtime.
The docs I must admit are not quite up to date. We have been pushing hard for Nodejs parity the last few dayys/weeks and are making great progress, however the docs and the site have not been updated in the same time just yet, so apologies for that.
Also, just as a fun fact: I noticed a spike in traffic and found this threat, so happy to take any requests but I'm not the OG of this threat haha.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#95I 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'm the founder of Perry) thanks for giving it a try and let me be upfront with you: Compiling express has been one of the hardest challenges for Perry. I'm 99% sure it still does not work out of the box just yet - which is why we pivoted to fastify more than express.
That said, the last few days we made great progress to get Perry to compile packages "lik" Express (lot's of dynamic imports) much better.
I'll retry this once our current batch of Nodejs parity issues are resolved.
Just to be clear though: No v8 runtime, we actually took out the v8 engine we had optionally included thus far because the benefits no longer outweight the disadvantages.
If you want to tag along the progres follow me on X (@proggeramlug), that's where I share the most up to date progress on Perry.
Also, it is definetely a goal to compile apps that use Express and that will happen - not commiting to a timeline but just in the last few days we got so much closer.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#96I'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…
thanks for bringing up the concern. I am proggeramlug (or amlug, either way), Ralph, founder of perry.
Yes, Perry is heavily AI-assisted - similar to the Bun to Rust port is too. Your concern is real and I don't claim to have all the answers for that.
I do know that AI is much better at finding bugs when it comes to compilers than most humans will ever be. Decoding bytecode and knowing what it should be is nothing humans are good at - AI does it trivially.
So yes, lots of AI, but this is not a "vibe-coded" slop project either. I have decades of experience in programming (native) and so I'm quite confident that this will work out well - but I totally see your skepticism.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#97Earlier quoted context omitted.
where exactly do you see comments by proggeramlug?
On other sites, like github and reddit. This exchange was funny though. He eventually gets called out by the other commenter to stop responding with an LLM: https://github.com/PerryTS/perry/issues/139#issuecomment-429...
Now, to tell you the truth, for a lot of tickets AI does generate legit the better answers than me. And my time is quite limited.
That said, I will always stand behind my posts, AI-assisted or not.
Now the thread you specifically point at here is ironic in many ways. The other guy says "and claude won't tell you that", while in fact Claude said (in my response) the exact thing he claimed Claude would not be able to do. Anyways, the technical merrits of the conversation are certainly worthwhile and important.
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#98I'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…
Hey smasher164, thanks for bringing up the concern. I am proggeramlug (or amlug, either way), Ralph, founder of perry. Yes, Perry is heavily AI-assisted - similar to the Bun to Rust port is too. Your concern is real and I don't claim to have all the answers for that. I do know that AI is much better at finding bugs when it comes to compilers than most humans will ever be. Decoding bytecode and knowing what it should…
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#99Earlier quoted context omitted.
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.
Of course there is a (native) runtime, as there is for all languages (like you said) :)
Re: Perry Compiles TypeScript directly to executables using SWC and LLVM
#100I 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…
Hey ventana, (I'm the founder of Perry) thanks for giving it a try and let me be upfront with you: Compiling express has been one of the hardest challenges for Perry. I'm 99% sure it still does not work out of the box just yet - which is why we pivoted to fastify more than express. That said, the last few days we made great progress to get Perry to compile packages "lik" Express (lot's of dynamic imports) much better…
Don't get me wrong, I'll be totally excited to replace my card game app backend with a static binary, that's why I immediately went on trying Perry :)
Just to give you an idea what I'm trying to achieve: I'm currently hosting it on a single VPS. Node is handling the average of 30 qps, peaking up to 100 qps, just fine, with P99 latency being safely below 100ms and only occasional spikes of P99 to up to a second. The spikes are probably caused by some VPS sluggishness as I just use filesystem to periodically dump the in-memory games state.
But I expect I might eventually start seeing performance issues, so rewriting to a language that compiles to a native binary is on the table. I was considering Golang or Rust; making the current codebase compile to a binary would be a miracle saving me quite some time, even if I just vibe-code the rewrite :)