Comment by DanRosenwasser

12 hours ago

Hey there, TypeScript team member here. The tsrs project has been extremely interesting to see come together. We've been working with the maintainers to better understand how tsrs is fast and what sorts of optimizations it uses are safe. We even did our own Rust vibe port and what we currently suspect is that a lot of the speed does not just come down to language choice, and some of what is going to make TS 7.1 faster and leaner (see the charts in the blog post) actually comes from optimizations discovered in tsrs.

We think the wasm and oxlint integration makes a lot of sense for Cloudflare's needs, so this investment makes sense. At the same time, we'll be working hard and collaborating to make the official TypeScript toolset faster and even more efficient.

Congrats to the tsrs team on making this official. We're excited and we look forward to continuing on collaboration!

At this point, why invest further in TSGO?

No matter how many optimizations can be ported from tsrs to ts-go, Rust will be more efficient and enable the WASM use case.

The premise of porting the compiler from TS to GO was ease of migration due to Go's garbage collector. That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.

  • > That doesn't hold anymore? AI doesn't care how hard or easy a migration is if a test suite exists.

    Sure, but that only matters if migration is going to be the last thing anyone does on a project. Unless you think typescript 7.1 ought to be enough for anybody, it also matters what the typescript team wants to write/read/reason in.

  • I just vibecofed tsasm. tsrs is obsolete now and anyone who still uses it is hopelessly behind the times. The tsrs team should delete the repository immediately and join my project.

    • Too late I just shipped tsvhdl so you have a hardware implementation of the actual TS compiler. Why steal valuable CPU cycles from agent workflows, off load all transpilation and type checking to a dedicated TSC chip.

      3 replies →

    • I am okay if agents can write code that is very safe in ASM. I am sure code written in Rust are naturally safe compared to asm or c. Waiting for tsasm to be significantly faster and safer than tsrs.

      9 replies →

    • Did you? GitHub link? because that would be awesome! which asm target did you pick? I looked at using LLVMs' LVM because I didn't want to have to choose ARM or x86? What are some of the trade-offs you made along the way? Wait, are you making a joke and think you're funny? (Hate to be the bearer of bad news but you're not.)

  • Your answer is within the comment you wrote. AI is maintaining tsrs whereas humans are maintaining tsgo.

    Your question boils down to "why would humans maintain something?" which could have a variety of answers depending on context.

  • I never understand why people say things like this. It is not uncommon for languages to have multiple implementations, everything must not be abandoned for Rust man.

    • There are precisely two languages that make the most sense to implement the TypeScript compiler in: Rust and TypeScript itself.

      A Rust implementation will have the fastest compilation speeds, memory safety, can easily be compiled to WASM, or compiled to a native node module.

      A TypeScript implementation provides the most convenient way for TypeScript code to use the typescript package as a library. Pure JS, no native code or WASM dependencies. No FFI tax, can be jitted.

      Go was always a compromise to make a port easier for humans. Go's GC makes it easier to keep the general code structure from the TS implementation. However that GC is also a liability, you sacrifice speed and embeddability.

      Personally I'd prefer they went back to TypeScript for the reference implementation, and used Rust for the performance implementation. Go doesn't bring anything to the table anymore.

      3 replies →

  • The reason Anders gave at the time was Rust effectively outlaws cyclic data structures, which was not fitting of their implementation.

  • Because TSGO is stable and compatible?

    I assume that most of the speedup in ts-rs does not simply stem from using a language without garbage collection, but actually from doing smart optimizations that can be done in any langauge.

    Similar to how uv in the Python world explained that their implementation being in Rust has very little to do with the most impactful speedups they did.

  • Another advantage of AI, though, is that it becomes easier to maintain more than one TypeScript compiler. Perhaps there's some benefits to having some diversity?

  • Please you port it if its so easy, the tests are available on gh. I wont be using an llm ported ts compiler anyways, and neither would many others

    Its a great way to divide and kill the popularity of your project. I made sure bun is no longer used in my devices or projects that depend on it for example, I'm not alone in this.

Thanks for the response and it is encouraging to hear that there's more to this project than vibe coding! Sounds like some interesting things were found in the process, and I'm all for vibe coding as a way to learn new things.

  • Im not because nobody actually ever learns anything. For every one person that learns something the other 99% of the population gets lazier and dumber, ponder how that might play itself out.

    This is probably the most harmful tech ever created simply because how many people trick themselves into thinking they're smarter while actually becoming much dumber. We're actually cooked.

Thanks for the input, glad to hear both parties benefit.

Could you elaborate on what type of optimizations were added to TS 7.1? As in, were they more algorithmic or related to memory management?

  • If I recall correctly, a few of both - there were instances where some work could be done more lazily/minimally (https://github.com/microsoft/TypeScript/pull/64476), and there were instances where we changed our allocation patterns and played around with some struct layouts. We originally strived not to drastically reorganize our data structures to make things easier to port, and we have more flexibility now. We're continuing to experiment more here.

Been with TS for many years now and the work your team's done over the years is amazing. Thank you

+1 from what I’ve seen, porting apples to apples to rust only impacts performance by a few % (sometimes in the wrong direction). The main speed up comes from algorithmic improvements that can also be applied to the original project.

Ah I was gonna ask what happened with tsc-rs by Theo but looks like you guys are merging it in, at least it won't be a waste of his $500k in token spend, lol.