Remix.run Logo
▲ DanRosenwasser 5 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!

▲samuelstros 5 hours ago | parent | next [-]

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.

▲magicalist 4 hours ago | parent | next [-]

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

▲collabs an hour ago | parent | next [-]

I would love this to be typescript 8 and 8.1 story (:

▲ 4 hours ago | parent | prev [-]
[deleted]
▲platinumrad 3 hours ago | parent | prev | next [-]

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.

▲written-beyond an hour ago | parent | next [-]

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.

▲cute_boi an hour ago | parent | prev [-]

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.

▲wavemode 4 hours ago | parent | prev | next [-]

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.

▲ 4 hours ago | parent | next [-]
[deleted]
▲greenavocado 4 hours ago | parent | prev [-]

No, the question is now: "How much human mental momentum, ego, and investment is there in and behind any particular project or its forks?"

▲stephbook 3 hours ago | parent [-]

I for one would be demotivated. Why maintain an official compiler that's not even half as fast as the vibe-coded one?

"Just" publish the language specs and be done.

▲Rapzid an hour ago | parent | next [-]

These ports are borrowing large parts of the architecture, algorithms, and data structures from the official implementation.

I don't think a spec would facilitate them at such a low effort level and cost.

▲greenavocado an hour ago | parent | prev [-]

> Why maintain an official compiler that's not even half as fast as the vibe-coded one?

Because at the end of the day, someone has to actually care and put in effort, even if the thing is machine generated, because it can go off the rails.

▲melodyogonna 3 hours ago | parent | prev | next [-]

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.

▲fallingbananna 3 hours ago | parent | prev | next [-]

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.

▲ 2 hours ago | parent [-]
[deleted]
▲skybrian 34 minutes ago | parent | prev | next [-]

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?

▲pier25 4 hours ago | parent | prev [-]

TSGO is already plenty fast and overkill for most projects.

Sure the Rust version is faster but the difference is probably only noticeable in the top 1% largest projects.

▲theappsecguy 4 hours ago | parent | next [-]

Fast is one thing, TSGO is fast enough I think, but my god does it suck up memory

▲alain_gilbert 4 hours ago | parent | prev [-]

I'm always mind-blown when I read stuff like "speed is overkill". Speechless!

▲pier25 3 hours ago | parent [-]

do you go to the supermarket with an F1 car?

▲tialaramex 6 minutes ago | parent | next [-]

I walk to the supermarket. I'm pretty sure an F1 car would be noticeably slower.

On foot I cross the little residential street where I live, walk to the corner, cross the busier road using a Zebra that was installed by thoughtful "pedestrian first" local government, then walk to the next corner where the main entrance to the supermarket is.

In the F1 car lets assume somebody already pre-warmed it and so it's ready to go (F1 cars do not "just work" like your family car because that's not required in the F1 rules) I walk to the car park and get in, I need to accelerate quite hard to get the slippery F1 car up the steep drive, but then brake hard to stop and have somebody else check both ways since an F1 car isn't equipped for this in a side street. Now I pull out, takes no time to reach that street where pedestrian me crossed but I can't use that route in a car, so, go through another residential area, turn onto an old main road, turn again, to a roundabout, go into the underground carpark of the supermarket. Once I've parked I'm about as close to the front door as if I were walking from the Zebra. Huh.

▲AnnikaL 20 minutes ago | parent | prev | next [-]

If you are travelling a long distance, say over 1000 miles/km, do you always drive? Or do you take an airplane (or a train)?

▲wiseowise an hour ago | parent | prev | next [-]

No, but I sure wouldn’t mind if I opened my fridge and the food was already there.

▲suriyaG 2 hours ago | parent | prev | next [-]

the cost between an F1 car and a "regular" car is high, both financially and functionally.

but tsrs and tsgo are not a similar comparison. they cost the same (you download a binary and run it) and are functionally identical. in that case why would you not use the faster & better one?

the question should be, do you always want your groceries 50% faster ?

▲sophacles 44 minutes ago | parent | prev | next [-]

Bad comparrison. The less time my computer spends doing things the less battery I use.

An F1 car goes faster but also uses more fuel to do so.

Any one tool being a bit faster doesn't make my batter last noticeably longer, but defaulting to using the efficient tooling gets me results I can see.

▲alain_gilbert 3 hours ago | parent | prev [-]

Do you usually dig up your garden by hand with a shovel, or do you use a rototiller?

▲pier25 3 hours ago | parent | next [-]

Now we're getting somewhere. This is a great example because obviously speed depends on the context.

Obviously a shovel is quite an improvement for home gardeners but big constructions need a completely different tool.

For +99% of TS projects going from eg 10ms to 1ms is not going to make any difference even though it's a 10x improvement. In part because most monitors refresh at 60hz (16ms per frame) but even with +120hz monitors this is not going to have an impact on any workflow. Even for CI network latency is going to be a much bigger factor than improving TS compilation beyond the performance that TSGO already provides.

▲eyelidlessness 2 hours ago | parent [-]

I think it might have more meaningful impact on high volume use cases, i.e. where cumulative run time is still significant.

That’s already meaningful for at least a couple of companies I’ve seen investing in these ports. It might be niche for individual dev workflows now, but as those evolve it could become less niche (albeit probably still less uniform).

▲seanw444 3 hours ago | parent | prev [-]

Do you dig your garden with an excavator?

▲wiseowise an hour ago | parent | next [-]

Why are bringing Java into this?

▲Tadpole9181 2 hours ago | parent | prev [-]

I mean... If I had an excavator it beats using a shovel? This is such a silly "gotcha" analogy because the only reason I wouldn't is cost. And cost is not a reason for tsgo to be slower?

"Would you rather have worse software for literally no benefit?"

We should aim to make software as performant, bug free, feature-complete, and maintainable as is cost effective. It's asinine to argue that software shouldn't be fast, not because of some trade off, but just because someone doesn't need it to be fast for small tasks.

Which, mind you, isn't even the case here. Thousands of businesses use typescript for millions of lines of code. Performance gains can mean tens of thousands of dollars in compute or hardware or time; tons of carbon saved from being emitted.

▲afiori 2 hours ago | parent | next [-]

Yep cost is the reason, allegedly the ts team found go a better language for a port and both using a less ergonomic language and switching target every six months have associated costs

▲Tadpole9181 an hour ago | parent [-]

And that's a fine argument to make! But this stupid garden analogy is nonsense.

▲ 2 hours ago | parent | prev [-]
[deleted]
▲egonschiele 5 hours ago | parent | prev | next [-]

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.

▲lemagedurage 5 hours ago | parent | prev | next [-]

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?

▲DanRosenwasser 4 hours ago | parent [-]

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.

▲zyf 4 hours ago | parent | prev | next [-]

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

▲satvikpendem 4 hours ago | parent | prev [-]

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.