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

21–30 of 109 posts

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

#21

Post by rzmmm »

fooker wrote: post #17
smasher164 wrote: post #13

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

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.

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

#22

Post by mirekrusin »

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?

if /comprehensive/ then ai

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

#23

Post by drawfloat »

madanparas wrote: post #14
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.

You're right. The typed buffer locals optimization keeps TypeScript semantics intact by exploiting the existing Buffer/Uint8Array type annotation to skip the NaN-unbox. It's not dropping types, it's using them. The floor I described applies to any-typed paths where static type info isn't available. For well-typed TypeScript, the roadmap shows the gap closes without semantic changes.

Put the LLM down and talk to humans as a human.

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

#24

Post by nielsbot »

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.

Why don't JITs preserve previous work across runs of the same code?

If you encounter code with the same hash as last time, load up the previously generated binary and run that... or is that already happening?

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

#25

Post by mirekrusin »

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.

Julia?

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

#26

Post by jeswin »

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

Add: A request is to explain how it works on the website. I did take a look at https://www.perryts.com/en/internals/ but are those techniques described really sufficient to express TS? Based on my experience, I must say I'm surprised. But the proof is in the pudding, and if it's compiling those examples it must be working somehow!

[1]: https://tsonic.org

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

#27

Post by manquer »

fooker wrote: post #17
smasher164 wrote: post #13

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

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.

Trust of a project long term always was and continues to be of concern when choosing a critical dependency .

The concern basically boils down to how large and serious is the team and what if they abandon the project in few weeks or months .

These were always the risks, many here have been burned by betting years of their career building against promising but what turned out to be weak projects

OP is alluding to the fact that today commit frequency, lines of code or how active the contributors in the issue trackers are no longer good signals to use as proxy.

When the underlying project to yours is few million lines of code written by machines only it is not going to be feasible fork and maintain or in-house it if the maintainers abandon it

To be clear users of a library or a tool aren’t owed anything when it available gratis and fully open source .

However not everyone has access to unlimited tokens to disregard the quality (in terms of history and usage ) or size of the underlying project completely

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

#28

Post by fooker »

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.

This is a very popular opinion that is sort of obsolete now in my opinion.

It was a valid concern last year. We have seen tremendous progress on this in the last 4-6 months.

Even if your initial prototypes are unmaintainable slop, the state of the art models are fairly good at refactoring and fixing things.

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

#29

Post by microtonal »

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?

Not X, not Y, just Z.

The whole site is very jarring to read.

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

#30

Post by fooker »

manquer wrote: post #27
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.

Trust of a project long term always was and continues to be of concern when choosing a critical dependency . The concern basically boils down to how large and serious is the team and what if they abandon the project in few weeks or months . These were always the risks, many here have been burned by betting years of their career building against promising but what turned out to be weak projects OP is alluding to the f…

I think the primary value of a project like this is the demonstration that this is possible and a proof that it does not incur some unknown tradeoff you'll discover after spending resources doing it.

IMO the maintenance story is more or less solved if you can keep AI agents refactoring and improving it in a loop.

> However not everyone has access to unlimited tokens

Apologies. I did not consider this when writing my comment, being spoilt by unlimited 'free' AI.

Free in quotes because, presumably, training agents on AI usage from developers is worth more than the cost of providing free AI.

Post reply on HN