thanks DanRosenwasser and team for building such an awesome tool for so many years!
And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-...
- LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build
which muddies the water a bit, but I'm sure we can get it working
I love TypeScript, if nothing else for how it's been able to popularize types.
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 believing that the untyped way is superior (unless you were forced to use a really bad typed language, I guess). And arguing that untyped languages are better without that experience is also not serious, in the sense that anyone can unseriously say anything if they don't care about being well-informed enough to be right.
[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
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 love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.
Static vs dynamic typing is no less ubiquitous in online forums over the decades than tabs vs spaces and vim vs emacs.
e.g. Gradual typing was since added to PHP and Python which ended some debate like how linting tools shut down a lot of whitespace debates.
In the early days they would often say things like "but we have prop types, why use TypeScript", "why not use JSDoc" (this made no sense at the time), or "it's an exercise in needless complexity". It was really tough to sell them on TypeScript for years.
I think there are developers who are very goal-oriented with a narrow perspective on getting from point A to point B, and their understanding of the process isn't particularly holistic, rigorous, or geared towards external or knock-on factors like maintainability, performance, bugs, etc. They deal with it when circumstances force them to, and no sooner. Defining types is a complete waste of time to someone like that.
These people thrive where teams are primarily expected to just ship things, and in my experience they often hate needing to think about things like types, tests, or code quality beyond running a linter.
So, they're serious people in one school of thought. They contribute meaningfully to projects. I think they're a large constituent of the new class of vibe coders who laugh at you if you look at the code. That's fine, they're doing their thing, and there are more than a few ways to get programs into people's hands. That way just isn't the way I like to.
Personally - I also think people really underestimate just how much the tooling around types has improved over the last 20 years.
If I'm having to try to look up the difference between iBrowserInterface6 and iBrowserInterface5 and iBrowserInterface4... (and yes - shit like this really did exist: https://learn.microsoft.com/en-us/windows/win32/api/shdeprec...)
And I have no tooling for autocomplete, and the docs are shoddy, and google is just coming on the scene...
People understandable want to throw their computer out the window.
Types are great. Some forms of them were not.
I just don't think this is true.
Frankly - it's hard to argue this at all (even today) given that JS is the dominate language on the planet, and it lacks types... as does python, which had a reputation for decades as THE language to use to teach new folks to code. Or take PHP which dominated server development for a LOOONG time: also lacks types. Ruby on Rails has a wonderful reputation as the "get shit done" framework: no types.
Types are good for modern software companies, where code size has ballooned up very high (common to work on a codebase with hundreds of thousands of lines) or teams are large (50+ developers) and terrible if you just want to hammer out something that works as a solo dev.
Do I like types today? Sure - the tooling is solid, and I work on large codebases with large teams.
Did I like types as a solo dev at 3 person startup? no.
https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...
That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.
There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.
> where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.
hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?
dimitropoulos•2h ago
huge congrats to the team!
looking forward to the Rust rewrite ;)
DonaldPShimoda•2h ago
(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
dimitropoulos•2h ago
hoppp•1h ago
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.
dimitropoulos•1h ago
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•55m ago
hebrox•34m ago
faefox•8m ago
nicoburns•56m ago
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.
tshaddox•1h ago
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)?
samuell•36m ago
https://spf13.com/p/go-the-agentic-language/