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

81–90 of 109 posts

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

#81

Post by mirekrusin »

cornholio wrote: post #35
mirekrusin wrote: post #25

Earlier quoted context omitted.

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'…

Julia sits somewhere between jit and aot, there is no interpreter part, if something is to be exectued, it's compiled to machine code.

The point is that you can have dynamic language that executes natively.

You can also compile whole program aot in Julia.

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

#82

Post by moron4hire »

jeswin wrote: post #65
Reubend wrote: post #48

Earlier quoted context omitted.

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 su…

> strict, deterministic subset of TypeScript I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list, and include it along with the large docs cleanup planned before v1. > Also, what's an "ambient surface…

> Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc.

FYI, just in case you didn't know, there is an ExpandoObject type in the System.Dynamic namespace that you could use to do this. IDK if you want to, but it's one of those less common .NET features that people tend to not be aware of.

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

#83

Post by Dylan16807 »

cornholio wrote: post #15
Dylan16807 wrote: post #12

Earlier quoted context omitted.

I think you mean you can't get that performance without monomorphization. When you know the types you can... ...wait, I went and looked up that file. "The Three Optimizations That Would Close the Gap" You're presenting the data from there in an extremely misleading way! They in no way need to drop any Typescript semantics to go faster.

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.

You can compile two versions, it's not a big deal. "Fundamentally no way" means you're trying to solve math proofs instead of going for practical speedups.

But this case I think they do know the number type for sure, they're just failing to optimize around that fact.

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

#84

Post by [deleted] »

pjmlp wrote: post #60
nl wrote: post #50

Earlier quoted context omitted.

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 /…

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

[deleted]

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

#85

Post by ozgrakkurt »

nl wrote: post #50
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 /…

It is not standard for “no runtime” to mean that. For example go has a runtime that is compiled into the binary or you can google c runtime and see a million ways the word “runtime” is used with c.

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

#86

Post by [deleted] »

Dylan16807 wrote: post #83
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.

You can compile two versions, it's not a big deal. "Fundamentally no way" means you're trying to solve math proofs instead of going for practical speedups. But this case I think they do know the number type for sure, they're just failing to optimize around that fact.

[deleted]

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

#87

Post by Alifatisk »

metaquestions wrote: post #16
afavour wrote: post #5

Fascinating. I've written cross platform (WASM, iOS, Android) libraries with Rust before and had a good time but Rust can be a pain too. Cross-platform Typescript is a really interesting proposition. That said, the more I think about it the more dubious I am. The site boasts no runtime dependencies but clearly it’s going to need things like a garbage collector, you can’t just magic that requirement away. At a certain…

how do one tell when text is ai generated - honest question. What are the tell tale signs?

I use this website, https://tropes.fyi/vetter, it apparently detectes Perry as pure ai slop website.

There is also, https://en.wikipedia.org/wiki/Wikipedia:Signs_of_AI_writing

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

#88

Post by Alifatisk »

Seems like many in the comments is confused and unsure how this project actually managed to accomplish all the claims the website. To me, after realizing its ai slop, I lost interest. I feel like we are seeing more and more of this scenario in here. Should we perhaps start adding a tag in the title to mention that its LLM assisted work?

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

#89

Post by IshKebab »

jeswin wrote: post #52
IshKebab wrote: post #44

Earlier quoted context omitted.

Uhm... You're trying to port Typescript's Typescript-to-Go port back to Typescript? Am I missing something?

Yes. :) With the goal of compiling it to native code. It's mostly a mechanical port. Hoping to do a Show HN maybe in a month.

But why? Go already compiles to native code. And there's already a Typescript compiler written in Typescript. This still makes no sense to me!

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

#90

Post by jeswin »

moron4hire wrote: post #82
jeswin wrote: post #65

Earlier quoted context omitted.

> strict, deterministic subset of TypeScript I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list, and include it along with the large docs cleanup planned before v1. > Also, what's an "ambient surface…

> Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. FYI, just in case you didn't know, there is an ExpandoObject type in the System.Dynamic namespace that you could use to do this. IDK if you want to, but it's one of those less common .NET features that people tend to not be aware of.

tsonic uses NativeAOT by default, and DLR/System.Dynamic isn't supported in NativeAOT. There are switches in tsonic to give you MSIL, but that's used mostly for testing or for compat reasons.
Post reply on HN