Live data from Hacker News

TypeScript 7

devblogs.microsoft.com

1–10 of 321 posts

Re: TypeScript 7

#2
the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out).

huge congrats to the team!

looking forward to the Rust rewrite ;)

Re: TypeScript 7

#3

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out). huge congrats to the team! looking forward to the Rust rewrite ;)

Most complex, perhaps, but not "most advanced". I don't think there's necessarily a meaningful "correct" choice for that title, but surely one of the proof assistant languages would be a more likely candidate?

(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)

Re: TypeScript 7

#5

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out). huge congrats to the team! looking forward to the Rust rewrite ;)

Most complex , perhaps, but not "most advanced". I don't think there's necessarily a meaningful "correct" choice for that title, but surely one of the proof assistant languages would be a more likely candidate? (I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)

good points, let's get negated types and higher kinded types in there then you've got yourself a deal. maybe regex thrown in too for flavor

Re: TypeScript 7

#6

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out). huge congrats to the team! looking forward to the Rust rewrite ;)

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.

Re: TypeScript 7

#7
post #6

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out). huge congrats to the team! looking forward to the Rust rewrite ;)

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…

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

Re: TypeScript 7

#8
really excited to see this release! i've been using TypeScript for several projects like https://github.com/dyad-sh/dyad which is >250k lines of TypeScript and the speed-up makes things like running typescript check as a pre-commit hook painless

thanks DanRosenwasser and team for building such an awesome tool for so many years!

Re: TypeScript 7

#9

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out). huge congrats to the team! looking forward to the Rust rewrite ;)

> most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out)

This TypeScript release is largely about performance. Isn't OCaml still at least twice as fast (and maybe even faster for incremental compilation on very large codebases)?

Re: TypeScript 7

#10
post #6

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out). huge congrats to the team! looking forward to the Rust rewrite ;)

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…

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.

Post reply on HN