Tsc-ts: TypeScript written in TypeScript(github.com) |
Tsc-ts: TypeScript written in TypeScript(github.com) |
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.
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.
Not quite for free. You’d have to target the subset of both TS and scriptc and differential test, since there exist programs that work in both TS and scriptc but produce different output
Edit: found it: https://github.com/tunnckoCoreHQ/tsgolint-rust
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?
On the other hand, time and time again it has been proven that it can be a good language to write tools that are perfectly sufficiently fast, like esbuild. With ts-go the choice to target Go instead of Rust seems to have come down to sensibilities and ease of translation, and possibly some other factors as well. I don't think they were aiming for maximum performance, and it would be unsurprising if you could squeeze quite a bit more out of ts-go itself with some effort.
The real benefit was getting the initial "10x" improvement, of course. Getting an additional 2x-3x is fantastic, but it's less noticeable when your codebase is already getting typechecked faster than you care to measure. For me even my largest codebases are chewed through plenty fast on ts-go, and I trust the TypeScript team to have done a good job (especially having seen some of their process for doing the port) so I think I'm good on missing out vibecoded Rust ports and whatnot. Interesting for sure, but we'll see how it all pans out in the long run.
If "scriptc" is so invasive it makes Typescript no longer even a garbage collected language then it really isn't Typescript anymore.
- 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!
The only thing that can be compared are language implementations. That a given implementation, such as GCC, 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 is inherently "performant"; C programs compiled with GCC and Clang are fast. The same program compiled with My Toy C Compiler, with none of the work that has gone into LLVM and the GCC backend, is going to have different runtime characteristics.
That's not true. Many languages make tradeoffs for performance. There are many things in JS (or Python) which make optimizations difficult and sometimes impossible. For example - obj[key] = "haha".
> ...than running a heavy weight vm.
would it not have been easier to start from v6, the one already in typescript?
First, you can't get very far without self-hosting. You'll need many extensions and hooks into the compiler, and those are probably all in TypeScript. You can't use the mainline tsc v6 compiler because it's slow and runs Javascript. scriptc will not be able to compile the v6 compiler into native code either, because that code is too dynamic. And you can't use v7 because it's written in golang.
So the only option is to rewrite it in typescript, and compile it into native code via scriptc itself.
We did exactly the same thing, and it's here: https://github.com/tsoniclang/tsts-legacy
We decided to move away from it, by writing a golang-to-typescript transpiler - https://github.com/tsoniclang/gotots. That produces a working typescript version automatically from Microsoft's v7 compiler, but we just decided to not proceed with that because (a) LLMs have gotten so much better at doing these rewrites, that it's not expensive to maintain a port and (b) looking at signals from Microsoft, they don't seem to be so sure of golang anymore. I suspect it's going to get rewritten in rust.
With how “cheap” it is to achieve now, I’m pretty sure they will too. Though things like that still worry me, core tools I rely on becoming LLM-ported blobs of code that no human understands is a bit scary. I guess I’m old fashioned like that
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.
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.
But for stuff like that, it is usually not often a problem since features are most often first built as a spec and a test(suite) which by itself makes the thing easier to maintain with vibe coding. Since the implementation in itself is not import, only that it works like the spec. But that works only for software that can have a well defined specification and a test(suite). Basically it only works for things that are formally verified through the spec, which is not a lot of things at the moment.
The answer, according to https://scriptc.dev/docs/limitations#weak-collections-and-me..., is that scriptc relies primarily on reference counting, augmented with a cycle collector that runs at specific times, kind of like Python.