The Perry runtime is surprisiginly small, especially since we (LLVM rather) strip out all that is no needed in one of the compile steps.

Of course there is a (native) runtime, as there is for all languages (like you said) :)

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.

Do you somehow find yourself with hundreds of comments to write and nary a moment to spare? Do you genuinely think Claude can better answer questions in your domain of expertise than you can? Is English a second language and not one you're comfortable writing in?

There are courses on how to use an LLM to better market to people, to do PR, to communicate with other people. Grifters don't care about the human aspect or whatever, their goal is to grift. Comments and other text are just a means to an end (money).

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.

(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.

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 :)

Doesn't avoid the runtime, but it made deployment really easy.

Otherwise, I'm just using Go for backend now.

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.

I have limited time, and the little feedback that guy provided turned out to be perfectly well answered by AI. So sorry, but either you actually criticize something actionable to just shut up, but I don't have the time to debate this if the simple few lines don't get answered.

If you would like more insight, just say the word.