[hoppp]

I am not sure a rust rewrite would be meaningful.

Go is great because it's fast to code.It's easy to reimplement typescript in go 1:1 just by looking at the code.

Rust on the other hand would take a lot longer to develop.

Maybe rust is 20% faster than go but overall the increase from typescript with go is good enough.

Maybe rust would yield a 14 times speedup over the 11 times in vscode but go is already good enough to make a huge difference.

[afdbcreid]

A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1.

But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.

[nicoburns]

The benefit to Rust rewrite would be integration with the rest of the JS tooling ecosystem which is increasingly written in Rust rather than performance.

It probably won't ever happen though.

> It's easy to reimplement typescript in go 1:1 just by looking at the code.

That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.

[Cthulhu_]

Can you elaborate why that's a factor? The tools are just binaries in how they're used, the language they're written in is no longer a factor then.

It's a good argument if you're talking about transferable skills though, I can imagine some contributors work on both TS and Biome, for example. This is why a lot of JS tools were initially written in JS, too.

[nicoburns]

> The tools are just binaries in how they're used

They are today, but the potential would be to expose something like the TypeScript compiler as a library. That is possible today with a lot of the JS tooling.

[dimitropoulos]

jokes aside, have you heard of the Jevons Paradox[1]? it feels like the "induced demand" effect to me with the whole "just one more lane" phenomenon you sometimes can see in roadways. when you increase the efficiency of a thing you thereby expand the set of things it can economically be used for, causing an overall increase in total consumption over time - not a decrease like you'd expect from just having made it much more efficient. "a smaller slice of a much bigger pie is still more pie" or something like that.

in TypeScript's case with the "pie" being compute time, things like HKTs (e.g. hotscript, hkt-toolbelt) that might not have made as much sense in the past suddenly become so much more feasible, but also are the very things that drag that hard-fought efficiency win back down into the mud. is it worth it? library authors will ultimately be the ones to decide the big chunks of that question by virtue of what they ship in their types.

[1] https://en.wikipedia.org/wiki/Jevons_paradox

[hoppp]

Yes, I saw the YouTube video about Jevons paradox from Hank Green yesterday. :)

[annjose]

The Jevon's Paradox. And it is not a paradox :-)

[regular_trash]

It actually is a paradox, a veridical paradox. But I'm splitting hairs lol

[hebrox]

*The

[faefox]

Fine, the Hank Green.

[tancop]

the difference is with roads you dont get a lot of good secondary effects, one lane is just like the next. benefits are linear with the cost so they balance out. but with typescript and software in general they can be exponential.

fast type inference unlocks brand new patterns that were too slow to be practical on the old checker. at least some of them will turn out to be useful for peoples projects. and its also great for legacy or less complex code bases that will get faster type checking for free.