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
Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?
I love TypeScript, if nothing else for how it's been able to popularize types.
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.
But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime.
Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like".
It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.
For example, I find it highly annoying to have to sprinkle type annotations all over the place when the compiler isn't smart enough to figure out what I mean, in the absence of ambiguity. Like imagine this C code:
int main() {
int i = 23;
auto j = i;
printf("i = %d, j = %d\n", i, j);
}
fn foo1() -> i8 {
23
}
fn foo2() -> String {
"foo2".into()
}
fn main() {
let f1 = foo1();
let f2 = foo2();
let f3 = f1 + f2;
println!("Hello, world!");
}
I love Rust's typing because it's helpful and makes strong guarantees about the program's correctness. I'm not "anti-typing" at all. I'm just not a big fan of languages that make you annotate everything everywhere. Back when such arguments were in fashion, a pre-auto C fan might reduce my whole argument to "you don't like typing, newbie!", which would make me roll my eyes and hand them a lollipop.
FWIW, I think TypeScript's pretty great. I never like JS. I tolerated it, and could use it, but didn't enjoy it at all. TS is fun, though.
Is strongly typed not “I compiler/runtime guarantee the bytes I read adhere to type T”?
In Typescript this is by design. The most obvious is array variance. Typescript makes them covariant because that's what a lot of sane TS and JS code uses them as, but they should be invariant because you can write to them.
Example:
const dogs: Dog[] = []
// A sound type system would error here,
// but there's too many useful cases where you want to do this
const animals: Animal[] = dogs
animals.push(new Cat())
animals[0].bark() // runtime TypeError hereI didn't go to college for software engineering or anything so when I ran into that for the first time I assumed there must have been some good academic reason that was simply beyond me as to why it was done that way.
It turns out that no, it's just as weird to those that do have the formal background, boy am I feeling vindicated ;)
class Animal { }
class Dog extends Animal{
bark(){return 1}
}
class Cat extends Animal{
bark(){return 1}
}
const dogs: Dog[] = []
const animals: Animal[] = dogs
animals.push(new Cat())
animals[0].bark() <<<<< "Property 'bark' does not exist on type 'Animal'."So:
i = 23 # Create an int(23) object and store its address in i
i = "foo" # Create a str("foo") object and store its address in i
> Python's strong typing mostly boils down to some operator rejecting mixed types.
Well... yeah. Turns out that plus duck typing is very nearly all most people want out of a type system. I went from Python to Rust and found nearly no difference in how they handle types, except Rust does it at compile time. Judging from the number of people I've seen make the same migration, that seems to be common. And yet no reasonable person makes claims that Rust is weakly typed, even when IMO it's basically Python but enforced at compile time.
> 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?
I'm increasingly convinced that "strong/weak" has no useful meaning. Some people regularly use it interchangeably with "static/dynamic", others use it to vaguely refer to how much casting exists in a language, or how easy it is to transmute a value of one type into a value of a different type. There is no academic definition at all.
Mostly it gets used as a kind of cheap attack - it's like the meme "it's over, I've portrayed you as the soyjack and me as the chad". Good languages are strong, bad languages are weak, so if I say your favourite language has weak typing, and my favourite language has strong typing, then it's clear that my favourite language must be superior.
In general, I think it's more helpful to just reference the specific language feature you're talking about. Rather than say that JavaScript is a weakly typed language, instead say that there are a lot of implicit type conversations. Rather than say Erlang is strongly typed, say that there is no variable reassignment or shadowing. That way, you avoid the ambiguity about what you actually mean when you talk about strong or weak typing.
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!
> if nothing else for how it's been able to popularize types.
This is such an odd, javascript dev take.
Even before JS became the language for everything, there was a good chunk of time - maybe between 2005 and 2015? - when Python and Ruby were dominant in this environment, and this dismissive attitude towards static typechecking was similarly dominant.
Of course in the enterprise space everyone was using Java, and in the systems space or game dev space everyone was using C++. But those worlds get a lot less airtime here.
Plus everyone on HN is a good little pg disciple, and Lisp is dynamically typed. If the One True Language doesn't need static typechecking (though SBCL offers some very helpful heuristics) surely it's not worth it. Right? Right?
Ish.
SBCL aggressively infers types wherever possible. It can do dynamic typing with tags of course. You can also write it with 100% static types.
Dynamic typing isn't a defining feature of Lisp style languages (even GC isn't necessary). Some historic Lisps and modern ones are 100% statically typed.
"Lisp" isn't a single language. Arguably the language people speak about when they say Lisp without qualifier, ANSI CL, allows conforming implementations (e.g. SBCL) to offer gradual typing, not just heuristics.
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.
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.
I am very perplexed by this. I am going through Neetcode's DSA course where he explains what RAM and arrays are, but then he goes on to say something like "but since we are going to use Python, none of this applies." Personally, I learned the most about how software really works from reading The Rust Programming Language. It not only teaches you how to program in Rust, but also how memory works, what a string really is, etc.
And before Java finally settled on what we have today, we had 3rd-party libraries like jodatime that tried to fix it.
I guess it’s in a good state today, but it took a LocalDateTime.MAX to get there. I mean an Instant.MAX. No, I mean an OffsetDateTime.MAX. No, I mean new Date(Long.MAX_VALUE). Oh wait I meant new Timestamp(Long.MAX_VALUE). No, I mean LocalTime.MAX.
I’ll stop now, but i could go on.
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.
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.
I think that comment is clear in that he likes to work alone which for problems of a certain size just isn't feasible
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.
1. 20% were type-coercion bugs, 30% were non-boolean values being passed to boolean-named fields (with some overlap with the former). Linters have come a long way, but compile-time type-checking is better in almost every way.
edit: the downvote button HN is not for disagreeing with comments or unpopular opinions. please dont turn hn into reddit.
huge congrats to the team!
looking forward to the Rust rewrite ;)
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.
But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.
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.
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.
fast type inference unlocks brand new patterns that were too slow to be practical on the old checker. at least some of them will turn out to be useful for peoples projects. and its also great for legacy or less complex code bases that will get faster type checking for free.
(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)
Honest question, what do you mean by this?
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)?
[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
As I understand it, Deno provides the "language server" for editors like VS Code. So how does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?
This means you need to plug an import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the import resolution code is in Rust. I’ve done a partial reimplementation in TypeScript using a coding agent, but there’s quite a lot to it.
I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.
And yeah, I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.
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.
thanks DanRosenwasser and team for building such an awesome tool for so many years!
- 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
And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-...
I am still of the opinion that well organized and named JS is all that anyone needs and typescript only exists for fresh graduates and fleeing OOP devs.
edit: also the downvote button HN is not for disagreeing with comments or unpopular opinions.
You probably didn't work on any medium or large codebase and didn't have to do a refactor.
> it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape
What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.
> What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.
did you? it was created by microsoft, a C# shop, to support their existing workflows around typing and hinting support. The typescript creation team was literally led by the guy who made C#.
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 have enough experience.
> it was created by microsoft
It was created at Microsft, but it was crated by Anders Hejlsberg who, I'm pretty, sure didn't want to just "create a safehaven to C# and java devs", he was actually solving real problems with JS development issues, completely orthogonal You can argue that first syntax was very C/C# inspired, and that Anders also created C#, but that's not what OP meant (or at least how it read).
A clean django project is probably 3-4x less code than the equivalent TS based service.
It made me consider dropping strict mode and defaulting to js for most simple things.
I run all my projects now in TypeScript with the strictest possible settings, including disabling `ts-ignore` markers.
(This would drive me absolutely insane, but my agents get over it pretty quickly!)
Databricks actually just posted some of their own benchmarks on how harness alone impacts costs https://www.databricks.com/blog/benchmarking-coding-agents-d...
simple things like passing more file context, model having to explore the code base at start of each session, writing comments or markdown docs ends up increasing, running into test / build issues can 3-10x your costs.
PS: my code is still mostly TS and rust but I'm considering moving some of my annotations into .d.ts files and having them generated from runtime types (ala MonkeyType).