I confirmed, it's faster than the Go version, which is very surprising, and super impressive!
Caveats:
- I don't think it's right to say that it's "written in TypeScript". In fact, it's written in the subscript of TypeScript that scriptc supports. scriptc isn't just a subset of ts; it even diverges from ts semantics in sneaky ways to facilitate its optimizations. So, these folks have really created a TypeScript-like native language with some kind of RC-GC hybrid and a bunch of caveats. Not clear if this is any better than just creating a new language.
- Very likely that it was codeveloped with scriptc, so it's getting maximum benefit from exactly the sorts of idioms that scriptc supports well. And, I would bet they landed optimizations to scriptc specifically to get this result.
This could be useful, assuming they invest in supporting it, and you're the sort of person who needs 2x faster ts compiles.
Well, if you write a library in the scriptc subset, it will also work in regular JavaScript runtimes, for free. (Unless you rely on, e.g., catching runtime errors thrown by failed casts, but that's easy enough to avoid.) That seems like a clear advantage over creating a new language.
What I do think would be nice would be if all the tweak-JS-semantics-for-optimization-purposes projects (scriptc, Static Hermes, Nova, possibly Closure Compiler) got together and agreed on a minimal set of rules that TypeScript code should follow in order to be compatible with all of them. Then there could be a push for commonly used npm packages to adhere to those rules, and advertise that they do so in order to be fully optimized.
There is another project that also converted the go version to rust and got 2x performance like bun did, but will also generate .d.ts files where bun does not.
The back and forth between writing tools in javascript and go or rust seems like it's in an unstable equilibrium right now:
- Go / Rust: It's easier than ever to rewrite existing tools in more performand languages
- Javascript: The v8 runtime for vercel or cloudflare workers is a much cheaper way to run certain workloads (e.g. conversational agents) than running a heavy weight vm. See just bash as another example project for taking advantage of this (https://github.com/vercel-labs/just-bash)
That's because there's no such thing as a "performant language". A programming language is inert. It's notation. The only thing that can be compared are language implementations. That a given implementation, such as the GCC backend, has an excellent code generator that emits efficient code is saying something about how great that code generator is. It's not that the input language has some inherent performance characteristics. Programming languages get run. The binaries do.
C programs compiled with GCC and LLVM are fast. The same program compiled with My Toy C Compiler with none of the work that has gone into optimizations is going to have different runtime characteristics.
Running Rust code in V8 via WebAssembly works today, though the tooling could benefit from a bit more polish. Go sort of works, but less well; IIUC fixing this would require adding more features to Wasm, most especially interior pointers, so that its garbage collection behavior can be made semantically compatible with Go's.
Those offer a more streamlined developer experience than traditional cloud VMs, but still require just as much compute resources (apart from being able to scale to zero if you can tolerate cold starts). E.g., you still have to choose how many data centers they run in and which ones, which is laden with tradeoffs, whereas every Cloudflare Worker runs in every Cloudflare DC, for free.
Cloudflare workers don't have cold starts? How do they manage that? I thought they'd still have firecracker or something underneath. Are they trusting the V8 sandbox that much?
"Native code" doesn't mean "as fast as the code can possibly be". The native code this produces is (apparently) better optimized than the code that the Go compiler produces. It's a given that the Go compiler will produce suboptimal code, if nothing else because it includes a garbage collector in the compiled code, which introduces overhead.
This version can additionally be compiled through LLVM, using a compiler from Vercel supporting a subset of TypeScript. I tried and it is 2 to 3x faster than the native Go version.
So it's just the compiling that's faster? Still not clear on the point of this, I have some pretty absurdly large typescript projects and have never felt that the compiler was slow, even before 7
There is no obvious explanation for why you would want this anywhere I can find... Does anyone understand? If you wanted this, wouldn't it make more sense to extend the last version of TypeScript before ts-go instead? Hmm.
Stage 1 to writing a bootstrap able language is using the intermediate step of compiling it with a compiler written in another language so that you can write a compiler for yours. I’m sure they did this in order to get a binary of the first self-compilable version.
Apparently it's 2/3 times faster than the Go version.
Whatever one think, the fact that there's 4 vibe coded compilers, 2 of those with 100% coverage of the official one and all being much faster than the Go version should be a wake up call for the TypeScript team.
Despite the resources and having a huge team of people that are clearly good at programming languages and compilers, something is definitely not working as it should there if vibecoders can get much faster fully compliant compilers.
"Vibe coded" and "supposed a lot faster than the competition" is becoming a smell to me. LLMs have a demonstrated capability to benchmarkmaxx that is even greater than human's already substantial capabilities to do so.
I'm not saying this isn't possible, I'm saying I'd wait a bit before I got too excited. That it seems to have held up to some other commenter's testing which was presumably not in the benchmark is an interesting sign, as a lot of time benchmarkmaxxed code falls over dead the instant you give it anything not in the benchmark. But I've still seen a whole bunch of projects "X times faster than what we told the AI to copy" that were less than met the eye to jump immediately to this must be awesome without more people trying it out seriously.
I think a bit differently. The real problem with vibe coding is that it's hard to write a precise specification of the problem. But if the specification is accurate, running the AI dozens of times tends to make it much faster than a human (purely from experience). However, for most problems where vibe coding is actually useful, a human still has to set the initial framing.
I confirmed, it's faster than the Go version, which is very surprising, and super impressive!
Caveats:
- I don't think it's right to say that it's "written in TypeScript". In fact, it's written in the subscript of TypeScript that scriptc supports. scriptc isn't just a subset of ts; it even diverges from ts semantics in sneaky ways to facilitate its optimizations. So, these folks have really created a TypeScript-like native language with some kind of RC-GC hybrid and a bunch of caveats. Not clear if this is any better than just creating a new language.
- Very likely that it was codeveloped with scriptc, so it's getting maximum benefit from exactly the sorts of idioms that scriptc supports well. And, I would bet they landed optimizations to scriptc specifically to get this result.
This could be useful, assuming they invest in supporting it, and you're the sort of person who needs 2x faster ts compiles.
Well, if you write a library in the scriptc subset, it will also work in regular JavaScript runtimes, for free. (Unless you rely on, e.g., catching runtime errors thrown by failed casts, but that's easy enough to avoid.) That seems like a clear advantage over creating a new language.
What I do think would be nice would be if all the tweak-JS-semantics-for-optimization-purposes projects (scriptc, Static Hermes, Nova, possibly Closure Compiler) got together and agreed on a minimal set of rules that TypeScript code should follow in order to be compatible with all of them. Then there could be a push for commonly used npm packages to adhere to those rules, and advertise that they do so in order to be fully optimized.
Did anyone benchmark against Buns‘ new time typecheck that landed in v 1.4.3? I would do it but too far away from my machine right now.
There is another project that also converted the go version to rust and got 2x performance like bun did, but will also generate .d.ts files where bun does not.
Edit: found it: https://github.com/tunnckoCoreHQ/tsgolint-rust
The back and forth between writing tools in javascript and go or rust seems like it's in an unstable equilibrium right now:
- Go / Rust: It's easier than ever to rewrite existing tools in more performand languages
- Javascript: The v8 runtime for vercel or cloudflare workers is a much cheaper way to run certain workloads (e.g. conversational agents) than running a heavy weight vm. See just bash as another example project for taking advantage of this (https://github.com/vercel-labs/just-bash)
I'm curious to see what happens!
That's because there's no such thing as a "performant language". A programming language is inert. It's notation. The only thing that can be compared are language implementations. That a given implementation, such as the GCC backend, has an excellent code generator that emits efficient code is saying something about how great that code generator is. It's not that the input language has some inherent performance characteristics. Programming languages get run. The binaries do.
C programs compiled with GCC and LLVM are fast. The same program compiled with My Toy C Compiler with none of the work that has gone into optimizations is going to have different runtime characteristics.
Running Rust code in V8 via WebAssembly works today, though the tooling could benefit from a bit more polish. Go sort of works, but less well; IIUC fixing this would require adding more features to Wasm, most especially interior pointers, so that its garbage collection behavior can be made semantically compatible with Go's.
Those offer a more streamlined developer experience than traditional cloud VMs, but still require just as much compute resources (apart from being able to scale to zero if you can tolerate cold starts). E.g., you still have to choose how many data centers they run in and which ones, which is laden with tradeoffs, whereas every Cloudflare Worker runs in every Cloudflare DC, for free.
Cloudflare workers don't have cold starts? How do they manage that? I thought they'd still have firecracker or something underneath. Are they trusting the V8 sandbox that much?
> An experimental TypeScript port of the TypeScript 7.0.2 compiler (TypeScript-Go, or tsgo), compiled to native code with scriptc.
I don’t get it. Isn’t the golang version already native?
Or is this one of those things where it’s not supposed to make sense?
"Native code" doesn't mean "as fast as the code can possibly be". The native code this produces is (apparently) better optimized than the code that the Go compiler produces. It's a given that the Go compiler will produce suboptimal code, if nothing else because it includes a garbage collector in the compiled code, which introduces overhead.
Is the Typescript not garbage collected somehow?
If "scriptc" is so invasive it makes Typescript no longer even a garbage collected language then it really isn't Typescript anymore.
This version can additionally be compiled through LLVM, using a compiler from Vercel supporting a subset of TypeScript. I tried and it is 2 to 3x faster than the native Go version.
So it's just the compiling that's faster? Still not clear on the point of this, I have some pretty absurdly large typescript projects and have never felt that the compiler was slow, even before 7
both tsgo and tsc-ts are native, tsc-ts is faster and still written in TypeScript. tsc-ts was built using scriptc, a TS-to-native compiler.
I don't know whats a meme or not anymore..
What is the purpose of this?
https://github.com/vercel-labs/tsc-ts/issues/196
There is no obvious explanation for why you would want this anywhere I can find... Does anyone understand? If you wanted this, wouldn't it make more sense to extend the last version of TypeScript before ts-go instead? Hmm.
Seems like it’s to show off scriptc unless I’m missing something else. They claim this is 2-4x faster than tsgo
https://t.co/fMEAmv2VDY
I guess the question is why you wouldn't use TypeScript 6 as the basis for that.
Stage 1 to writing a bootstrap able language is using the intermediate step of compiling it with a compiler written in another language so that you can write a compiler for yours. I’m sure they did this in order to get a binary of the first self-compilable version.
All the twitter types are busy rewriting typescript to speed it up, just because they can. It's becoming a meme.
Seriously, the simulation needs a reboot.
What if we're actually running in a slop decomp of the simulation...
Or needs to be rewritten in Rust.
Now someone's gotta port this version to rust.
Now someone's gotta port this to rust.
Will it be faster than the Go version? But why is this even necessary? I don't get it.
Apparently it's 2/3 times faster than the Go version.
Whatever one think, the fact that there's 4 vibe coded compilers, 2 of those with 100% coverage of the official one and all being much faster than the Go version should be a wake up call for the TypeScript team.
Despite the resources and having a huge team of people that are clearly good at programming languages and compilers, something is definitely not working as it should there if vibecoders can get much faster fully compliant compilers.
"Vibe coded" and "supposed a lot faster than the competition" is becoming a smell to me. LLMs have a demonstrated capability to benchmarkmaxx that is even greater than human's already substantial capabilities to do so.
I'm not saying this isn't possible, I'm saying I'd wait a bit before I got too excited. That it seems to have held up to some other commenter's testing which was presumably not in the benchmark is an interesting sign, as a lot of time benchmarkmaxxed code falls over dead the instant you give it anything not in the benchmark. But I've still seen a whole bunch of projects "X times faster than what we told the AI to copy" that were less than met the eye to jump immediately to this must be awesome without more people trying it out seriously.
I think a bit differently. The real problem with vibe coding is that it's hard to write a precise specification of the problem. But if the specification is accurate, running the AI dozens of times tends to make it much faster than a human (purely from experience). However, for most problems where vibe coding is actually useful, a human still has to set the initial framing.