191–200 of 321 posts
Earlier quoted context omitted.
Do you think Bun's migration was irresponsible?
It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.
Earlier quoted context omitted.
I don't think ... serious people... argued that. That's a bit hyperbolic so I'm sure I'm wrong, but I have an ace: if you point me at very smart people who argued against types I'm gonna say that they weren't serious. I think it's not possible, if you have the relevant experience of working on both typed and untyped codebases of at least moderate complexity with at least one collaborator, to come away seriously belie…
They're still right here in sibling comments
was amusing to come back hours later and find out whether this comment ended up more upvoted or more downvoted, it was oscillating all day...
Earlier quoted context omitted.
It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.
yeah but, the existing code was also full of bugs, so isn’t it all a wash in the end?
Over the past year, I've been working on porting the v7 tsgo compiler back into TypeScript - https://github.com/tsoniclang/tsts
It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.
Congratulations! Although I'd prefer the C# authors to rewrite it in C# AOT :)
Earlier quoted context omitted.
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…
Not sure I understand. Bun's changes are merged on the dev branch and available for use, no? EDIT: Oh, look, blog post on the front page now. https://bun.com/blog/bun-in-rust > Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now. So, yes, it seems it was definitely more than a "marketing stunt" and it's broadly available and…
Earlier quoted context omitted.
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…
Not sure I understand. Bun's changes are merged on the dev branch and available for use, no? EDIT: Oh, look, blog post on the front page now. https://bun.com/blog/bun-in-rust > Bun v1.3.14 was the last version of Bun written in Zig. Bun v1.4.0 will be the first version of Bun written in Rust. It's available in canary now. So, yes, it seems it was definitely more than a "marketing stunt" and it's broadly available and…
Remember when people would argue about how types weren't worth the effort? I love TypeScript, if nothing else for how it's been able to popularize types.
Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell! P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language. Once you see what good application of types look like , is far better sell!
Functional programmers keep hyping up ADTs like this but the normie programmer doesn't care about ADTs or immutability. What really brought back static types was Golang & typescript, both have local variable type inference, good IDE support & other tooling, and (at least superficially) lighter weight syntax than Java. Normies don't care about algebraic types, pattern matching, immutability, referencial trasparency, type classes. What matters is libraries and tooling.
Earlier quoted context omitted.
dhh is still not very fond of it. To each their own. https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
> 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…
Me when my manager asks to complete the JIRA ticket.
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…
> It’s worth calling out that workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7. This is mainly because TypeScript 7 does not yet expose a stable programmatic API, and so tools (such as Volar) which embed TypeScript into their own compilers and language services can only currently rely on TypeScript 6.0. We expect this to be a point-in-time issue, as we are committed to providing a solution here. We will be actively working with the maintainers of these projects to ensure TypeScript 7 supports these workflows.