211–220 of 321 posts
Earlier quoted context omitted.
Type systems just used to be bad. Anything that forces you to use a class hierarchy to represent an "OR" type (sum types) is painful to work with. Modern languages like TypeScript / Rust / Swift / Kotlin that have sum types are dramatically much nicer.
C also has sum types.
I'm glad the JSDoc type syntax is still getting some focus. It's my favorite way to use typescript in my own projects. Some of the syntax changes will be annoying to update but most of them seem to be for the better.
I'm glad that TypeScript uses JSDoc and not the hideous XML format [1] that Microsoft's other languages use. [1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.
Earlier quoted context omitted.
Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear. Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.
Bun's migration to Rust was nothing more than a marketing stunt to sell more Claude subs under the impression it can perform this kind of work at scale, assuming that most who were convinced by it wouldn't look under the hood at what really took place. It has its merits as a proof of concept that could eventually be cleaned up and released properly later, but I can't see it any other way. Too many see it as this mira…
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…
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.
Types are a safeguard, they rule out certain errors. So using them is mostly for maintainability, and especially in large codebases and teams that becomes a thing. I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
> Types are a safeguard, they rule out certain errors I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
Earlier quoted context omitted.
> Types are a safeguard, they rule out certain errors I have migrated to TypeScript just about a year ago and it's my third try to migrate to TS from JS during the last decade and finally a successful one. While TS went a long road since the first versions which were incredibly hostile, my rewrite of a large codebase from js to ts revealed exactly zero type-related bugs.
Static types are not _that_ useful to catch bugs, if only because type related bugs tend to surface very quickly, especially in strongly typed language like Python. So a good CI suite is usually enough to catch them, but you do need good coverage. Even if they make it to prod, they won't survive long... Static types are IMHO more useful for speed, maintenance/refactoring of large projects, and code completion in IDEs…
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.
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 reasonable - it’s not set up that way by default.
2. Rust Analyzer / cargo check is inefficient and throws a lot of data away each time instead of caching it. So in a larger project you’re waiting on it to catch up. Waiting on Rust Analyzer to check my code is easily the largest amount of time wasted, more so than actually compiling it.
But it should be said that this is being worked on: https://rust-lang.github.io/rust-project-goals/2025h2/relink...
Earlier quoted context omitted.
> TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become `any`. No thanks! That comment is expected by a Ruby enthusiast, which is arguably one of…
I'm a Ruby enthusiast - Sorbet is one of the best things since sliced bread to happen to the ecosystem. matz is pushing hard on static typing as part of the standard Ruby ecosystem as well.
A lot of Rubyists deeply care about code aesthetics and Sorbet annotations are unfortunately quite ugly. There are also RBS comments, which look a bit better, but tooling/LSPs are not quite there yet IME.