231–240 of 321 posts
Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?
This is build-time performance, not run-time.
Does lack of compiler API mean typescript-language-server is not going to play nice with 7.0?
I know this is about Typescript. But I am wondering if anything happening in Go that will make this even faster?
Performance improvements, yay ! It always surprises me how little complaints there have been on HN about tsc's performance. I do both TypeScript and Rust at work, and I've seen orders of magnitude more comments on the web about how “rustc is slow” than complaints about tsc's performance and it never stops to surprise me given than in practice the later have annoyed me consistently more than the former.
I think Rust is noticeably slow for two reasons: 1. The default settings aren’t well optimized. So the pattern a lot of people fall into is: start a project and everything’s fast, then add more code and dependencies and everything gets super slow. Then you Google how to fix it, change some compile settings and restructure your project and it speeds up again. Rust requires knowledge and effort to keep compile times re…
Performance improvements, yay ! It always surprises me how little complaints there have been on HN about tsc's performance. I do both TypeScript and Rust at work, and I've seen orders of magnitude more comments on the web about how “rustc is slow” than complaints about tsc's performance and it never stops to surprise me given than in practice the later have annoyed me consistently more than the former.
I didn’t care. Because to me the performance was a cost I was more than willing to pay for giving me sanity in JS land. Knowing you were passing the right types, right number of arguments, etc. Just the quality of documentation you got from having types at all above the nothing we had before was huge. I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
Exactly, no sound people should consider using another language because the CI takes 4 minutes to run instead of 12 seconds.
Yet on HN people complain about rust being “unusable because the compiler is too slow” in every other thread…
I know this is about Typescript. But I am wondering if anything happening in Go that will make this even faster?
Just about every release of go has incremental performance improvements [1]. It's a very stable language, so don't expect anything mind-blowing. For example the latest 1.26 moved a new garbage collector from experimental to production [2]. In the latest compiler they state that: "The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance". [1] https://go.dev…
Thanks for the link.
The speed up numbers based on their testing: Codebase | TypeScript 6 | TypeScript 7 | Speedup ------------|--------------|--------------|-------- vscode | 125.7s | 10.6s | 11.9x sentry | 139.8s | 15.7s | 8.9x bluesky | 24.3s | 2.8s | 8.7x playwright | 12.8s | 1.47s | 8.7x tldraw | 11.2s | 1.46s | 7.7x Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun). Quic…
Do you think Bun's migration was irresponsible?
Earlier quoted context omitted.
> You really should just not assume things about people with no reason other than "they dont like the things i like That's not the reason for my comment. I truly don't understand how after so many years someone "isn't sold" on TypeScript. Sure, you don't have to use it if you don't want to, but if don't see how it's truly essential in current JS development, I don't know what else to assume, other than OP doesn't hav…
Its not essential. Good organization. Good functional configuration. Proper separation. Good variable naming. All of these things are what make it more than easy to work without type declaration. People have been working on huge code bases without types for a VERY long time with no issue, especially in functional paradigms.