YHK - yet another hacker news clone

tsc-ts: TypeScript written in TypeScript

33 points tosh 2 hours ago 30 comments

drewbitt 2 hours ago | parent

I don't know whats a meme or not anymore..

perganomoly 1 hour ago | parent

Seriously, the simulation needs a reboot.

dalmo3 1 hour ago | parent

Or needs to be rewritten in Rust.

staminade 1 hour ago | parent

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

jchw 1 hour ago | parent

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.

phoghed 1 hour ago | parent

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

ameliaquining 1 hour ago | parent

I guess the question is why you wouldn't use TypeScript 6 as the basis for that.

reactordev 1 hour ago | parent

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.

9cb14c1ec0 1 hour ago | parent

All the twitter types are busy rewriting typescript to speed it up, just because they can. It's becoming a meme.

tallowen 1 hour ago | parent

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!

CharlieDigital 51 minutes ago | parent

    > ...than running a heavy weight vm.
Serverless containers are a thing (GCP Cloud Run, Azure Container Apps) and seems like the right analogue.

ameliaquining 46 minutes ago | parent

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.

aftbit 48 seconds ago | parent

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?

ameliaquining 51 minutes ago | parent

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.

koolba 1 hour ago | parent

> 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?

clarus 1 hour ago | parent

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.

monster_truck 42 minutes ago | parent

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

brazukadev 20 minutes ago | parent

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.

anonymous908213 18 minutes ago | parent

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

einaralex 1 hour ago | parent

What is the purpose of this?

jdw64 1 hour ago | parent

Will it be faster than the Go version? But why is this even necessary? I don't get it.

epolanski 51 minutes ago | parent

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.

jdw64 34 minutes ago | parent

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.

pizlonator 59 minutes ago | parent

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.

ameliaquining 37 minutes ago | parent

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.

_1tan 48 minutes ago | parent

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.

sroussey 28 minutes ago | parent

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

simonbw 35 minutes ago | parent

Now someone's gotta port this to rust.

simonbw 35 minutes ago | parent

Now someone's gotta port this version to rust.