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.

Edit: found it: https://github.com/tunnckoCoreHQ/tsgolint-rust

That's because there's no such thing as a "performant language". A programming language is inert. It's notation. Programming languages don't get run. Binaries do.

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.

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.

    > ...than running a heavy weight vm.

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

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.

This entire industry has become a meme.

https://github.com/vercel-labs/tsc-ts/issues/196

What if we're actually running in a slop decomp of the simulation...

Or needs to be rewritten in Rust.

I'll take a shot at this even though I have no connection to vercel or scriptc. I have been working on tsonic.org for a year - which is a transpiler which will let you transpile typescript to rust, c# and mojo instead of javascript.

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.

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

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.

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.