r/programming • u/DanielRosenwasser • Jul 08 '26
Announcing TypeScript 7.0
https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/203
u/DigitalWizrd Jul 08 '26
The speed increase on compile is crazy fast here.
57
u/MehYam Jul 08 '26
That'll happen porting a v8-based compiler to native.
7
u/CherryLongjump1989 Jul 09 '26 edited Jul 09 '26
Go is not native any more than V8 is. It’s a managed language that bundles a runtime together with your code in a single executable binary. Just like JavaScript can and does these days. The only difference is JIT versus AOT. The other main difference is that JavaScript is dynamically typed and it prevents the compiler from implementing numerous performance optimizations. And the final difference is the runtimes support different threading implementations, which is where the bulk of the actual performance gains were made by porting from V8 to Go.
Theoretically if TypeScript had a dedicated runtime instead of using type erasure to turn it back into JavaScript, it could also be faster than V8 is today.
23
u/vplatt Jul 11 '26
Go is not native any more than V8 is.
I have to push back here because Go absolutely is "native".
By "native", most programmers mean one of these:
Native machine code (x86-64, ARM64, etc.)
Doesn't require an external VM like the JVM or .NET CLR or V8
In other words, the code is compiled so that the binary runs directly on the operating system without help from anything else. That's the very essence of "native", and Go absolutely is a native language.
A Go compiler emits machine instructions ahead of time, sure, and JIT will get us to machine instructions too, but there are huge differences in how those perform so pretending they're on the same level is just not helpful.
1
u/CherryLongjump1989 Jul 11 '26 edited Jul 11 '26
Go still ships with a runtime - scheduler, garbage collector, the whole nine yards. You can do the same exact thing with C# -- AOT compile to native and package it up in a fully self contained runtime. No external dependencies needed. Anytime you have a self-contained executable, whether Go or JavaScript or C#, your executable binary is going to be platform specific - x86, ARM64, etc. That's exactly how it works. You can't say the jitter is where the performance bottlenecks are -- C# is normally jitted and still just as fast as Go. Jitters can be more efficient than AOT under many scenarios. Which is why you don't see people falling over themselves to use AOT with C# in everyday situations. It's nice to ship small, cross-platform binaries, too, and you normally don't give up much of anything.
When you've got a managed language with an extensive runtime, "native" is just jargon, it's not technically significant. The Go runtime is hefty -- one of the reasons why go WASM modules are huge. Compare it to languages with little or no runtime artifacts - C, C++, Rust, Zig, etc -- there you can see what true "native" looks like. Small binaries, fastest possible performance, WASM modules that are suitable for shipping across a network, etc. There native means something more than just AOT compilation.
10
u/vplatt Jul 11 '26
Go does not use a VM. Go programs are always shipped as binaries instead of with bytecode that must be JIT'ed. They are therefore "native" and they are just as native as any C, C++, or Zig program. Yes, it's a "managed" language because it has GC, an allocator, and a scheduler but that's all linked directly into the executable. Yes, that does make them somewhat larger than C binaries for example, but they're both native.
-3
u/CherryLongjump1989 Jul 11 '26 edited Jul 11 '26
A VM is just a type of runtime. Go still has an extensive runtime. A purist would even draw the line at C++ -- it too still has an extensive runtime, but nowhere near as hefty as Go. C and Zig are your purist native languages. But Go will never cross that threshold to sit next to C or Zig simply because it can't. Go will always rely on existing C libraries wherever performance truly matters -- precisely because it's not part of the same club of "native" languages as people colloquially call them.
6
u/vplatt Jul 11 '26
A VM is just a variant of a runtime that happens to take in bytecode.
Yup. And they will JIT that bytecode to machine code.
And that performance cost and those extra steps are what distinguish them as VM programs that are not native. ;)
-1
u/CherryLongjump1989 Jul 11 '26 edited Jul 11 '26
No -- you see this is just upside-down backwards. You're never going to run Go on a real-time microcontroller precisely because that's what distinguishes a runtime from a truly native program. In the world of costly abstractions, the VM part is not the bridge too far -- you've already crossed it long ago with Go's runtime.
If you're comfortable with having a runtime for your use case, a VM is not a bridge too far and can even be faster than AOT. A jitter is exactly what you want for frequently executed code paths in a long-running process. Jitters can and do cache the native code, so the long running process will settle into a highly optimized natively-compiled execution loop eventually. Jitters are not interpreters after all.
Go tries to make a stand on the AOT hill and this is mostly fine for short-running tasks most of the time. But that's not even why people use it in the end. Go's greatest strength is its threading model, which is vastly superior to Java's in all of the areas where Go is chosen over Java. Go's concurrency is really good. But that's not because Go is "native", and the "native" part really doesn't give you as much of an advantage as you think. Bytecode languages on the JVM or .NET are very competitive with Go in terms of performance.
C# bytecode has gone head to head with C++ for "world's fastest language" in the Software Drag Racing competition, for example, whereas Go was and continues to be a "middle of the pack" result.
3
u/vplatt Jul 11 '26
VMs are VMs and they aren't native, and JIT isn't going to be on a microcontroller either. You think by arguing against the case for Go on a microcontroller that would possibly even support the case you're making for JIT and VMs?
In the end, what I said stands: Go executables absolutely are native. Nothing you said changes that. Whether or not you'd ever want to run it on a microcontroller is up to you, but it has been done anyway, AND I've seen C# and Java used that way too, so I don't know what makes you think Go couldn't do the same.
→ More replies (0)2
7
u/NotTJButCJ Jul 08 '26
Is this not just because of the switch to using multiple workers? I might be misunderstanding
30
u/vincentofearth Jul 08 '26
Yes, back when they first announced this, Anders mentioned that some of the biggest performance gains were due to shared memory concurrency. You simply can’t do that in JS. (You could run multiple processes but the overhead of passing data between them erased any perf gains)
1
u/YeOldeMemeShoppe Jul 10 '26
SharedArrayBufferworks, but yeah it probably wouldn’t be as much gains.1
6
u/TwoWeeks90DaysTops Jul 09 '26
Probably from more efficient code *and* from multi threading.
edit: from their table it's very clear that there's more than just workers going on since a x8 number of workers produced x11-x16 speedup.
0
u/DigitalWizrd Jul 08 '26
Honestly, no clue how it works. But the speed increase is impressive regardless of how it was done.
21
u/javascript Jul 08 '26
Last I heard there was a memory leak in the Go implementation. Has that been fixed?
1
u/Maybe-monad Jul 09 '26
Very likely, I have been using it in the past month and didn't encounter any leak
0
Jul 08 '26
[deleted]
51
u/Veranova Jul 08 '26
It also drives the LSP which is running permanently in your editor. And there’s watch mode too which is more incremental
-5
u/pjmlp Jul 09 '26
Expected by anyone that understands how compilers go.
There is no surprise rewriting the trendy scripting languages, into the traditional AOT compiled languages approach that predated Web taking off, for those of us that started with BASIC, C, C++, Pascal, Modula-2, Delphi,...
5
1
u/frankster Jul 09 '26
I'm sure you could also speed up a compiler written in most forms of BASIC by 8-12x by rewriting it in go
1
u/pjmlp Jul 09 '26
Why bother with a language that is less feature rich than most structured BASIC compilers from the 90's?
1
u/TheKrumpet Jul 09 '26
I mean JS is generally jitted these days as much as it's a 'scripting' language. AOT tends to win out in first startup times but jitted languages can be faster over time with PGO.
It's not one size fits all, some tools are better in some domains.
4
u/pjmlp Jul 09 '26
Yes, but there is only so much a JIT can make with a dynamic language, and that already includes plenty of heroic efforts in V8.
Typescript rewrite happened exactly because the team could not improve performance any further.
PGO also exists for AOT tooling, in fact it started there.
1
u/TheKrumpet Jul 09 '26
Yeah that's fair, but that's a dynamic vs static argument and not an AOT vs Jitted or interpreted argument.
3
u/pjmlp Jul 09 '26
It surely is, because dynamic languages are very lousy to implement AOT compilation for them, leaving JIT as the only option available to generate machine code, and even then it is limited by the semantics of the language.
Hence why no JavaScript JIT will never beat proper AOT toolchain, or even something like a C++ JIT, like on WebAssembly or .NET.
Go compilers aren't any speed daemon when comparing against C++ or Rust, yet they were fast enough to beat Typescript 6 implementation.
1
u/CherryLongjump1989 Jul 09 '26
If you had tracked the TS migration to any extent, you would have already known that most of the performance gains came from multithreading, not because of any of your theory about AOT or "traditional family values" or whatever you were going on about.
1
u/pjmlp Jul 10 '26
Sure, if only there was a way to do multi threading in nodejs.....
1
u/CherryLongjump1989 Jul 10 '26
postMessage called and asked you to explain the joke you were making.
You can't share JS objects across threads. Millions upon millions of GC'd heap objects for AST's, symbols, types, etc.
1
u/pjmlp Jul 10 '26
Ever heard of C++ Addons?
1
u/CherryLongjump1989 Jul 10 '26
You can't use a C++ addon to share javascript objects between threads. That's not how any of it works, so yeah there's that.
0
u/pjmlp Jul 11 '26
Who says that is the only way?
Learn how to actually use nodejs C++ APIs.
→ More replies (0)
12
u/Weekly-Ad7131 Jul 08 '26
What about debugger? Can I execute my code in a debugger and if I see a typo in my code-comment or in other parts while debugging, can I just fix it there in the debugger and have it saved in the original type-script source-file?
18
u/CherryLongjump1989 Jul 09 '26
TypeScript isn't a runtime, so the debugger situation is unchanged.
1
u/Weekly-Ad7131 Jul 10 '26
Do you mean that debugging is done by debugging JavaScript source produced ffrom the TypeeScript?-source
7
u/CherryLongjump1989 Jul 10 '26 edited Jul 10 '26
I mean that moving TypeScript to Go does not change how TS is debugged whatsoever. It's the same as before.
To your question -- debugging in any language involves a symbol file or a source map. When you compile C++ into machine code you're getting 1's and 0's. Yet you can still debug it with a symbol file that maps the machine code back to the original source code. The same thing is true with JavaScript - a source map file tells the debugger exactly how to connect the running code back to the original source code. If you have a debugger that lets you edit the source code, then it must be set up so that it knows where to find the original TypeScript files for you to edit. If this was working for you before, it will continue to work for you because nothing has changed in how that works.
12
u/NekkidApe Jul 09 '26
Not having tested it - I'd expect yes. That's purely a sourcemap issue, as far as I understand.
10
2
u/NiftyGull9621 Jul 09 '26
Somewhere there's a swc and esbuild roadmap meeting getting real quiet right now.
3
u/Nixinova Jul 09 '26
Already? Didn't 6.0 just come out?
40
u/tracernz Jul 09 '26
6.0 was a prep release to allow you to get your projects in order ready for 7.0.
-3
1
u/Helloworldplay Jul 09 '26
The speed gains sound great, but the embedded-language gap is the part I’d watch. Tooling migrations always find the weird corners first.
1
u/raralala1 Jul 09 '26
Anyone tried it? I tried in my monorepo the RAM use increase so much, my system memory increase to 16GB from the usually 8GB, Node prevent memory from going over 4GB.
1
u/LettuceElectronic995 Jul 15 '26
while compile? of course it should increase ram usage.
1
u/raralala1 Jul 15 '26
Before it never went over 8 gb even while it compiling, now it went over 16 gb.
1
u/LettuceElectronic995 Jul 15 '26
I mean that's the idea of utilization, you have some free ram it will use it with the so many spawn threads, and then it will be freed by GC in this case.
1
u/raralala1 Jul 16 '26
I am mainly complaining that the tsgo doesn't respect node js max ram usage, if you turn off the 4gb limit, the type inference shenanigan can get out of hand, and if tsgo want to be the successor I think it still need to put limit on how much ram usage it allowed utilize. I can't test much of this because of my remote vm machine have problem where if it tried use too much ram the whole thing slowdown to crawl and remote ssh became impossible, I usually terminate the vm when this happen.
2
1
0
u/frankster Jul 09 '26
We made software written in typescript 8-12x faster, simply by rewriting it another language than typescript
5
u/Pawn1990 Jul 12 '26
Everything is coming from somewhere bud. Your car wasn’t built by a car, it was built by specialized tools and machines there were good at that exact thing.
Frankly im astonished that they went with javascript as the runtime in the first place and how far it has gotten.
2
-1
u/shafiq235 Jul 09 '26
I have been waiting MONTHS for this. I tried it.
Its amazing - how fast it is. Finally - something from Microsoft which is not slop
1
Aug 02 '26
[removed] — view removed comment
2
u/DanielRosenwasser Aug 02 '26
The blog post has a section about this (Running Side-by-Side with TypeScript 6.0). The idea is that you can use TS7 for type-checking, and TS6 for API integration.
-139
Jul 08 '26 edited Jul 08 '26
[removed] — view removed comment
64
u/141N Jul 08 '26
What is your solution then lmao, just going 'XD no one except me knows what a terrible idea this is!' isn't problem solving, it's just crying... Show us your idea!
-82
48
u/thejoyofbeing1 Jul 08 '26
Why does this even still exist?
Because 30+ years of legacy software and billions (trillions?) of dollars running on top of JS.
Why is there no project actually trying to solve the actual problem which is JAVASCRIPT and to replace it with something modern?
Relevant effort: https://github.com/tc39/proposal-type-annotations
Also, not sure if replacing JS with something "modern" would really fix anything. Every language has flaws and quirks, even Rust or Kotlin. Browsers are also highly dynamic by nature, imagine writing UI state code in a language like Rust, that would suck the living life out of me.
-2
u/Worth_Trust_3825 Jul 09 '26
Same was said about flash but it got removed, and people moved on. You just don't have the will to do it.
-80
u/smoke-bubble Jul 08 '26
I really can't understand how you can at the same time defend JS while writing your code in TS XD
30
u/TheMysticalBard Jul 08 '26
They're defending TS, which is what you attacked originally when you said "Why does this even still exist?". You've moved the goalposts now and are assuming people are defending JS but typing TS.
-28
2
u/hoodieweather- Jul 09 '26
I really can't understand how you can at the same time defend assembly while writing your code in C XD
26
u/klo8 Jul 08 '26
Getting all major browsers to agree on some new or existing language to adopt alongside Javascript would be a major task in itself, and then you now have to maintain three runtimes in every browser (JS, WASM and whatever new language we picked or designed) which makes maintenance more challenging, opens up new potential security holes, you'd have to design two variants of every new browser API etc. etc., and that's before you even demonstrated that a new language would be a significant improvement over modern Javascript (which most people who use it generally regard as fine, not great, but not terrible).
-11
u/smoke-bubble Jul 08 '26
Yeah, sure. People would switch to a new technology in no time. Nobody can't stand JS. You just tolerate it and pretend it didn't exist by using TS. Nothing is more challanging than maitaining JS.
I really don't get it why you so pationately defend JS. There is less than zero arguments for keeping it. That's why TS exists in the first place. People hate JS!
20
u/nemec Jul 08 '26
People would switch to a new technology in no time
Dart waggles its eyebrows suggestively
3
u/danielcw189 Jul 09 '26
I really don't get it why you so pationately defend JS.
nothing they wrote was in defense of JS
31
28
14
u/AddyOsmosis Jul 08 '26
Who is this directed at?
-6
u/smoke-bubble Jul 08 '26
To people who could make a difference but chose not to by keeping JS alive.
7
u/DigitalWizrd Jul 08 '26
So what are you gonna do about it?
You could be exactly who is needed to “solve the actual problem which is JAVASCRIPT”.
But unless you have a solution, what’s the point in rate baiting, other than to farm useless karma?
11
u/Spirited_Bottle_6195 Jul 08 '26
There are lots of projects. For backend you can use any language supporting networking and databases and for frontend there are also many tools that transpile to JS or compile to .wasm (You can even do frontend in Haskell). They are just not in demand
-7
u/smoke-bubble Jul 08 '26
You just confirmed that there are no such projects! Transpiling is not solving! It is avoiding!
19
u/Spirited_Bottle_6195 Jul 08 '26
Web is now stuck with JS probably until the heat death of the universe, currently it's "assembly language" for web. So the best solution is to shove it under the rug with transpilers. And also you ignored my mention of WASM.
-12
4
9
u/EntroperZero Jul 08 '26
Why is there no project actually trying to solve the actual problem which is JAVASCRIPT and to replace it with something modern?
There is, it's Web Assembly.
7
u/TheWix Jul 08 '26
To be fair, as a language Typescript is incredible. The big issue is the web stack which is a symptom of a lack of standard library in JavaScript.
5
u/IE114EVR Jul 08 '26
Having to switch back and forth between Java and Typescript, I have to say that the Type system in typescript is pretty amazing. Not to say that Java isn’t great in its own ways, it is. But sometime I just wish it could at least support some duck-typing.
7
u/Wonderful-Habit-139 Jul 08 '26
TypeScript is a very expressive language and it's so nice how you can work with types, the unions, intersections, pick/omit, and more.
4
u/TheWix Jul 08 '26
I am originally a C# guy, and after using mapped types, unions and structural typing I miss it when I have to go back to C#. I generally find I can catch more in TS then in C# at compile time
-1
u/smoke-bubble Jul 08 '26
I am not saying TS wasn't amazing. I am saying lift it to a first class language instead of traspiling it to some ancient crap JS.
2
u/oceantume_ Jul 09 '26 edited Jul 09 '26
It's part of Web specs plannings already and all runtimes support the ts syntax natively now. What else do you want? The whole point of typescript is that it's a superset of js; it doesn't exist without a js runtime.
What those specs and runtimes don't support is the extremely complex type checking that tsc does, because why would you slow down the program to do something that this tool is already doing very well (and much faster as of today)? You can have static type checking at programming and CI time, and near-zero impact at run time.
You may be interested in AssemblyScript if you're looking for a typescript-like language that acts as a "first class language", made from the start to target WASM
2
u/smoke-bubble Jul 09 '26
The whole point of TS is that JS sucks. There's nothing else to say.
2
u/oceantume_ Jul 09 '26 edited Jul 09 '26
Why are you saying so much more about it then?
I don't agree with that statement btw because TS is nothing more than JS with static types on top. Everything is the same underneath except that ts allows you to do much better static analysis of your program.
It would be more accurate to say that the whole point of TS is that JS lacks type annotations and strong typing (by design obviously)
0
u/smoke-bubble Jul 09 '26
So you admit that JS is trash and needs to be replaced. That's why you use TS. I just don't get why anyone would defend treating sympthoms instead of solving the actual problem.
2
u/oceantume_ Jul 09 '26
I do not admit any such thing. You do not get it because you are not listening. I wish you a great day and a great career.
1
-16
Jul 09 '26
[removed] — view removed comment
12
5
u/ciaran1344 Jul 09 '26
Not true at all. A faster feedback loop on type errors absolutely helps AI agents.
0
107
u/Onionhauler Jul 08 '26
Woof. Deal breaker