@jarredsumner
the knock on server-side JS has always been that you only use it because you already know it. rEaL enGiNeeRs use Go or RuSt
LLMs know every language so that doesn't matter anymore, but the substance behind that knock is still true - JS uses more memory and CPU
Why are there like six parsing passes?
Why does the trimmer think Bun.Archive is in use when you have a property named “Archive” somewhere?
The results are exciting, but these questions sound like a bug farm.
The main mistake in the draft PR is the internals are not good enough.
Too many string lookups for things the AST already knows.
Why are only 38% of Claude Code’s types known?
Why are instruction counts for typed operations often higher than untyped?
I don’t recommend using it yet, there’s a follow up PR that needs to be merged but should be merged in like 12 hrs
Haven’t spent much time yet on binary size. Mostly on cpu and memory usage.
Context
TS 6 vs TS 7 is a great repo for benchmarking this since it’s a very close Go implementation of the same code, so I can tell claude make the instruction counts roughly match Go’s
@theo Currently, for HTTP server-like workloads yes. For long-lived CLIs, it’s better.
But it’s barely using the types so far. So I think there’s a lot of room to improve.
@iamelcharitas Already implemented :)
Explicitly specified types that don’t match throw a TypeError. This is probably the biggest breaking change - lying about types throws
however, LLMs are also really good at writing compilers.
so instead of you rewriting your app in another language, what if we just rewrite the compiler to make JS/TS perform competitively with Go and Rust
then rewriting your app might not be worth it, even if it’s easy