They've had a preview version of this available as ts-go for a while now, and I've been really happy using it on my projects. I just installed it and changed "tsc" to "tsgo" in a couple places and it just worked. I don't remember exact numbers, but I think an approximately 10x speed up is a reasonable estimate for my build times. They went from noticable-but-not-bad to imperceptibly-fast.
I'm looking not only for better build times, but for lower memory usage - running few LSPs on a large TypeScript codebases currently takes a lot of RAM.
This sounds really great. As a Go developer I'm also really looking forward to their Go port of the filesystem watcher package — I agree that the existing packages don't fully allow to do a reliable recursive directory watch and it would be great to have something where you don't rely on C dependencies just for this thing.
Building @parcel/watcher was always a huge PITA. I also hope they release this package separately because it’d be nice to have an easy to install, on any OS, file watcher that doesn’t require C++ toolchain.
Thing is file watching is not in a great place on linux w.r.t inotify and fanotify. In all my usecases present and past, I either just did a full scan each time (btw, this can be done extremely fast even on an entire homedir @ >4M entries/s)
Or recently I use an eBPF-based file watcher. This needs the client to run a transient process with cap_perfmon and cap_bpf that sets up the ring buffers and exits. After that, any unpriveleged process can read from that ring buffer at any time and it just works.
inotify works just fine for stuff like project watchdirs, but I wanted one for a whole home directory where it had lots of issues, fd limits, race conditions in situations like mkdir -p a/b, and renames/mv being hard to deal with, etc.
Been using tsgo for months and unfortunately had many random crashes, the speedup made it worth it though. Looking forward to try the release candidate.
I'm looking forward to this. But it does amaze me how Microsoft with all it's power takes years to complete the port to a different language and bun does it in 7 days. Crazy times
Bun does zero work in relation to TypeScript's type system. Since it's a strict superset, it is "simply" stripping types to execute the resulting JavaScript. That is effectively what it boils down to.
TypeScript is the most complex type system in existence. I am unsurprised it is difficult to port, but I am still a bit surprised by the length of the project thus far.
They've had a preview version of this available as ts-go for a while now, and I've been really happy using it on my projects. I just installed it and changed "tsc" to "tsgo" in a couple places and it just worked. I don't remember exact numbers, but I think an approximately 10x speed up is a reasonable estimate for my build times. They went from noticable-but-not-bad to imperceptibly-fast.
I'm looking not only for better build times, but for lower memory usage - running few LSPs on a large TypeScript codebases currently takes a lot of RAM.
This sounds really great. As a Go developer I'm also really looking forward to their Go port of the filesystem watcher package — I agree that the existing packages don't fully allow to do a reliable recursive directory watch and it would be great to have something where you don't rely on C dependencies just for this thing.
> As a Go developer I'm also really looking forward to their Go port of the filesystem watcher package
You plan to contribute to the TypeScript project?
No, in fact I do not use TS at all :).
However they did mention this in the article, and hopefully that also means they'll make the package accessible to others too:
> The watcher is a self-contained package that has allowed us to keep a clean separation of concerns between what we care to watch and why.
Building @parcel/watcher was always a huge PITA. I also hope they release this package separately because it’d be nice to have an easy to install, on any OS, file watcher that doesn’t require C++ toolchain.
Thing is file watching is not in a great place on linux w.r.t inotify and fanotify. In all my usecases present and past, I either just did a full scan each time (btw, this can be done extremely fast even on an entire homedir @ >4M entries/s)
Or recently I use an eBPF-based file watcher. This needs the client to run a transient process with cap_perfmon and cap_bpf that sets up the ring buffers and exits. After that, any unpriveleged process can read from that ring buffer at any time and it just works.
inotify works just fine for stuff like project watchdirs, but I wanted one for a whole home directory where it had lots of issues, fd limits, race conditions in situations like mkdir -p a/b, and renames/mv being hard to deal with, etc.
Been using tsgo for months and unfortunately had many random crashes, the speedup made it worth it though. Looking forward to try the release candidate.
I'm looking forward to this. But it does amaze me how Microsoft with all it's power takes years to complete the port to a different language and bun does it in 7 days. Crazy times
That made me wonder, since bun natively supports typescript, is it already using some kind of rust implementation of typescript?
Bun does zero work in relation to TypeScript's type system. Since it's a strict superset, it is "simply" stripping types to execute the resulting JavaScript. That is effectively what it boils down to.
TypeScript is the most complex type system in existence. I am unsurprised it is difficult to port, but I am still a bit surprised by the length of the project thus far.
Probably because TypeScript is too important to leave it purely to AI. The gall to question Anders Hejlsberg :D
> TypeScript 7.0 is often about 10 times faster than TypeScript 6.0
amazing
I need to know whether the speedup holds for truly gigantic projects such as Doom in Typescript types.
This is using their new Go based compiler, so I imagine so.