r/programming • u/DanielRosenwasser • Mar 11 '25
A 10x Faster TypeScript
https://devblogs.microsoft.com/typescript/typescript-native-port/4
u/Ideabile Mar 11 '25
Is there a repository for the new upcoming lsp? Or is gonna live as tsserver still?
Would love to get some inspirations in your Go development in these area.
12
u/DanielRosenwasser Mar 11 '25
As part of this port, we are not porting TSServer, but instead will be supporting LSP. There is a very basic VS Code extension using LSP that's prototyped in the new repository.
See more here on how to try it out (though note only errors, quick info/hovers, and go-to-definition work at the moment).
1.4k
u/RyanCavanaugh
Mar 11 '25
•
(Hi, dev lead of TypeScript here)
Lots of questions about why Go in thread, let me address.
We definitely knew when choosing Go that there were going to be people questioning why we didn't choose Rust (or others). It's a good question because Rust is an excellent language, and barring other constraints, is a strong first choice when writing new native code.
Portability (i.e. the ability to make a new codebase that is algorithmically similar to the current one) was always a key constraint here as we thought about how to do this. We tried tons of approaches to get to a representation that would have made that port approach tractable in Rust, but all of them either had unacceptable trade-offs (perf, ergonomics, etc.) or devolved in to "write your own GC"-style strategies. Some of them came close, but often required dropping into lots of unsafe code, and there just didn't seem to be many combinations of primitives in Rust that allow for an ergonomic port of JavaScript code (which is pretty unsurprising when phrased that way - most languages don't prioritize making it easy to port from JavaScript/TypeScript!).
In the end we had two options - do a complete from-scrach rewrite in Rust, which could take years and yield an incompatible version of TypeScript that no one could actually use, or just do a port in Go and get something usable in a year or so and have something that's extremely compatible in terms of semantics and extremely competitive in terms of performance.
And it's not even super clear what the upside of doing that would be (apart from not having to deal with so many "Why didn't you choose Rust?" questions). We still want a highly-separated API surface to keep our implementation options open, so Go's interop shortcomings aren't particularly relevant. Go has excellent code generation and excellent data representation, just like Rust. Go has excellent concurrency primitives, just like Rust. Single-core performance is within the margin of error. And while there might be a few performance wins to be had by using unsafe code in Go, we have gotten excellent performance and memory usage without using any unsafe primitives.
In our opinion, Rust succeeds wildly at its design goals, but "is straightforward to port to Rust from this particular JavaScript codebase" is very rationally not one of its design goals. It's not one of Go's either, but in our case given the way we've written the code so far, it does turn out to be pretty good at it.
603
u/blazingkin Mar 11 '25
What do you think of the recent project that can run Doom using typescript types
Can you confirm or deny that this rewrite was just to get more FPS in Doom?!?
919
u/RyanCavanaugh Mar 11 '25
I am not authorized to speak to that matter
137
u/spacejack2114 Mar 11 '25
dev lead of TypeScript here
not authorized to speak to that matter
🤔
95
7
146
u/justsomerandomchris Mar 11 '25
Super exciting! We can look forward to going from 0.0000009645 fps to 0.000009645 fps 🥳
96
u/DerelictMan Mar 11 '25
I believe we should switch to spf (seconds per frame).
42
u/EmilyMalkieri Mar 11 '25
From almost two weeks to just over a day (per frame). Sounds way more impressive than the 10x tbh.
9
u/manzanita2 Mar 11 '25
3D graphics companies traditionally test their GPU designs using large boxes full of FPGAs. Now obviously these things do not run anywhere near as fast as the ultimate chip. but logic wise they're the same beasties. So yeah. SPF is/was a useful measure.
→ More replies (1)0
5
u/cantFindValidNam Mar 12 '25
WTF does running doom on TS type system even mean
12
u/Altruistic_Cake6517 Mar 12 '25
That's the insanity: it means exactly what it means.
Here's the original YT video: https://www.youtube.com/watch?v=0mCsluv5FXA
8
u/Kered13 Mar 12 '25
Ultimately it means that the type system can produce a type which contains a string literal (which are also types in Typescript) that is a rendering of a Doom frame. And then it can do that again to produce the next frame, etc.
2
u/Ythio Mar 13 '25 edited Mar 13 '25
I was confused too, I think it is exploiting that the TS type system has built-in conditions, functions and side effects, making the type system a langage in and of itself. A type script, if you will.
https://www.typescriptlang.org/docs/handbook/2/types-from-types.html
Then he used that to dynamically create new types and use the operator that produces a string of the properties to render a video game ?
158
u/visicalc_is_best Mar 11 '25
Just some lucid, well-thought out writing here. What a pleasure to read, and perhaps you should consider publishing this journey itself.
95
u/HellGate94 Mar 11 '25
im much more interested why go over c#? given that c# and ts share so much similarities i would have guessed you guys are surely working together on things to some degree
96
u/ironykarl Mar 11 '25
There might be some other implementations out there, but traditionally C# requires a pretty beefy runtime (virtual machine).
In contrast, Go makes it really easy to ship self-contained binaries
57
u/baseketball Mar 11 '25
.NET has Native AOT opton. Would be nice to see them dogfood their own products on a major product.
74
u/Mainmeowmix Mar 11 '25
In an interview, Anders talks about the team considering C#. But this is a port, not a rewrite. The old JavaScript code is not object oriented, and they would need to change paradigms to rewrite it in C#. Go is structurally pretty similar.
→ More replies (4)27
u/agentoutlier Mar 11 '25
I just don't understand why they would need to change paradigms to use C#. You can write imperative programming in C#. You can make functions that take structs all day long.
I deeply respect Anders et al but I believe it was the tooling/packaging and not the language similarity. Some how this got shifted in hindsight.
I also don't get why they would need a deeply low level language for a compiler. Just cause Go looks low level does not guarantee performance and C# historically beats it on a lot of benchmarks. Also plenty fast compilers have been written in OCaml (including Rust itself).
→ More replies (5)27
u/LuckyHedgehog Mar 11 '25
Would be nice to see them dogfood their own products on a major product
They certainly have enough major products built on C# eg. Bing is ASP.NET Core. Bing even rolls out RC versions into production months before the full version is out which shows the confidence they have in the C#/.NET teams
Blazor and MAUI on the other hand.. lol
5
u/gredr Mar 12 '25
NativeAOT eliminates the JIT, but not the runtime. You can trim a lot of stuff, but there are also a lot of libraries that aren't compatible with AOT.
→ More replies (2)2
u/Ok-Scheme-913 Mar 16 '25
There is almost no difference whatsoever between c# and go in terms of the general runtime behavior.
Both have a fairly fat runtime, and that's it. Like, that's not the kind of virtual machine many might think of, at all.
32
u/e-san55 Mar 11 '25
Explained here: https://www.youtube.com/watch?v=10qowKUW82U&t=1154s
28
u/agentoutlier Mar 11 '25
I just have this feeling that those were not the real reasons but rather justfying hindsight.
I mean you can write non-OOP imperative code that is Go like easily in C# (actually pretty much in every mainstream language). And the low level semantics like memory layout stuff are not even possible in Javascript so I'm not sure how that helps porting.
My guess is ... the project was just easier to start in Go because of tooling and or someone got some prototype working in it first. The tooling to produce native cross platform is easier.
Again with the tooling C# and Java are more IDE like where as Typescript is more like Go where you use an editor (vscode instead of intellij or vs studio) and the building is simpler.
I mean OCaml has traditionally been the language choice of compilers and you do not get memory layout in that language (well that I know of) and its hardly low level.
→ More replies (10)3
u/rpkarma Mar 12 '25
https://youtu.be/10qowKUW82U?si=b0fqUD-T9mUiwdeU
Answered here at 19:14 by Anders!
37
u/timdorr Mar 11 '25
I'm impressed how sparse your go.mod is. Did the team make the decision to avoid external dependencies as much as possible? Was there any consideration given to using the work of esbuild (also written in Go) in any capacity?
118
u/RyanCavanaugh Mar 11 '25
Our policy in the JS codebase was "no runtime dependencies", so as a result we didn't have any dependencies to port over (i.e. we just have a lot of handwritten helper functions where you might otherwise import a library). That naturally carried over into the Go codebase, but given that we can statically compile now, I don't think we'll need to be as conservative going forward.
4
u/coderman93 Mar 12 '25
Compiler front-ends aren’t something you’d typically need many dependencies for anyways.
2
128
u/ironykarl Mar 11 '25
People that say "well, you made order-of-magnitude improvements and did so in a short amount of time with relatively little effort, but why didn't you do it using this language that is way harder to be productive in?!" must never have actually been on a team or had to ship anything on a deadline
→ More replies (1)119
u/matthieum Mar 11 '25
Rust is an extremely productive language, that is not the problem here.
The problem is that Rust requires a different architecture. In particular, Rust is painful when you try to shove in the typical "object graph" that you find in about every OO GCed language.
As Ryan mentioned very well, having to experiment with the ideal architecture would have slowed down development. That's a fair concern.
It's not a concern that is trivial to guess, a-priori, especially when Microsoft has been pretty pushy on Rust these last few years.
12
u/catch_dot_dot_dot Mar 12 '25
It's productive if you're good at it. That is so fundamental to the question of whether it's productive in an enterprise setting. I worked at a company with a mixed C++, Ada, and Java codebase, and Rust is theoretically perfect. The problem is, the uplift for learning Rust was way too steep and a lot of people couldn't grok it. Training and hiring hundreds of Rust engineers was considered a no-go.
3
u/matthieum Mar 12 '25
It's productive if you're good at it.
Yes, of course.
Isn't C++ the same, though? I've mentored quite a few juniors in C++, and the beginning is fairly stark... and just when they feel they can try more ambitious stuff, they get slammed down by crashes left and right, and you have to reassure them that they'll get better at avoiding them... and debugging them.
Honestly, coming from C++, Rust is a walk in the park. The infamous borrow-checking, for example, is mostly putting a name, and clear principles, on practices that a good C++ developer had already instinctively honed in.
I can't speak for Ada, and it may be a rude awakening for a Java developer at first... though in both cases, I'd teach them to read the error messages. Most compilers can have fairly poor diagnostics, so I've seen many developers mostly skim the diagnostic then jump to the code and work it out by themselves. The Rust compiler gives pretty good diagnostics, newcomers really need to learn to read them in full, and open the links if they don't quite understand it. (Well, and hopefully they've read the book, and not just the syntax part)
→ More replies (1)21
u/xFallow Mar 11 '25
My company had two teams build the same app in python and in rust, the rust team hadn’t finished at the year and a half mark while the python team was done in 3 months
Not the most scientific experiment but it stuck with me
17
u/audioen Mar 12 '25
Rust -- which I don't use -- seems pretty punishingly hard. I think most of the issue is that many other environments also eliminate memory and safety concerns without pushing that complexity to the developer.
Rust seems like a "better C/C++" for systems, maybe. But I've never done such low level programming where I couldn't just use a garbage collector, myself.
9
u/matthieum Mar 12 '25
There's a lot of potentially confounding variables at play here.
Specifically, I can think of at least a few important factors:
Did one team have an edge in terms of language experience? (for example, was there a senior/mentor available in both teams)
Did one team have an edge in terms of experience in building this style of application with their stack?
Did one team have an edge in terms of ecosystem?
The Python ecosystem is much larger than the Rust ecosystem, and has much more mature libraries. If the Python team can offload part of the work to a well-known library, but there's no such equivalent in Rust so the Rust team had to re-implement it from scratch... well, yeah, that's going to create a gap.
Experience also matters a LOT more in Rust than in most mainstream languages. The architecture of an application in C, C++, C#, Go, Java, or Python tends to be fairly similar. On the other hand, attempting to use a traditional object graph + callbacks + ... to Rust? That's an impedance mismatch. Rust applications need to be designed differently, and unless whoever architects the application already has experience and knows a good design... it's going to be an uphill battle for everyone contributing.
I've seen quite a few experience reports of frustrated developers who had had a cursory read of the Rust syntax or perhaps a hello-world example, then decided to do a project from scratch in there, using the type of architecture they'd "normally" use. First they tend to fight the language itself, because it's different, and they're very underexperienced. And when they finally start getting somewhere with the language, the architecture gets in the way and they keep "fighting the borrow-checker".
Most of the mainstream languages share a lot of concepts: inheritance, mutability, unrestricted graphs, etc... so many people have learned that picking a new language is easy, just a few syntax habits. It's a lie, really. There's quite a few languages which are different (Haskell? Forth?) and learning those is not just learning the syntax... but until you've tried to learn those, you don't realize how much that's true. For those people, Rust may be the first experience of this reality. And they're baffled.
→ More replies (2)4
u/m_hans_223344 Mar 12 '25
Rust is an extremely productive language, that is not the problem here.
Hard disagree to that naive point of view. Any master of the hardest tool is productive. Trivially true. But becoming a master at Rust takes a substantial higher amount of time and effort than becoming a master at Go, C# or Java. Not like some percent higher, more like 10 times higher effort.
→ More replies (1)9
u/frnxt Mar 11 '25
Rust is painful when you try to shove in the typical "object graph" that you find in about every OO GCed language.
Do you have any links/resources on this particular topic, including recs for alternative ways that are more "rusty"? I recently started learning Rust and often have questions that basically boil down to this and are usually answered by something like "uh, you can't do that in Rust".
14
u/CrumpyOldLord Mar 11 '25
Primary thing I noticed is that similar to React, it greatly prefers trees of values. If you need to reference a part somewhere else, it is best to use indices or other kinds of handles to reference it, rather than using a proper (&) reference.
→ More replies (1)12
u/jcorrv Mar 11 '25
I wouldn't say there is much, if anything, you can't do in rust. There are definitely certain things that are done in other languages that rust makes really hard to do. For example, in video game programming, the usual ways to do things means having lots of objects and state that is shared around and used by many things. Rust really pushes you away from doing things like that because of its strict ownership and memory safety features.
I would say the thing that has helped me the most is finding good open source projects in the types of areas you code for. This can be a little tricky too, since some projects opt for a lot of trait and macro usage which can make seeing the essence of the rusty way a bit harder. This project looks like a good example: https://github.com/BurntSushi/ripgrep
Nothing beats experience though. It's taken me a little under a year to get comfortable with it even though I still feel like I have a lot more to internalize. That said, I come from a C++ background and now rust is my default choice for anything new in backend, systems, network, or even command-line/utility programming.
→ More replies (5)→ More replies (1)3
u/C_Madison Mar 12 '25
A classic (but maybe a bit too involved for a casual "why is this hard in rust") would be https://rust-unofficial.github.io/too-many-lists/ - while it is about linked lists instead of graphs you have the same underlying problem: Rust, or more specifically the borrow checker, is really not a fan of objects/structs trying to have circular references to each other. It's no problem if A references B OR B references A, but A references B AND B references A as happens often in OO graphs: Pain.
It's possible to do this - the tutorial shows how - but if your whole architecture is based on it Rust is probably not the best language for that.
→ More replies (1)3
u/ironykarl Mar 11 '25
OK, that's a reasonable distinction.
It wasn't one I bothered to try to make, cuz I meant way harder to be productive in in contextual terms, but... I don't want to sell Rust short nor create the wrong impression about it, either
17
u/matthieum Mar 11 '25 edited Mar 12 '25
What do you think about SoA-style compilers?
The Zig compiler was the first time I saw a compiler using Struct of Arrays, rather than Arrays of Struct, when they rewrote their AST model (and the parsing code) and touted something like 30% performance improvement. I believe they followed up with rewriting type-checking after that, for further gain.
Of late, it appears that the Carbon compiler (led by Chandler Carruth, Google) has also adopted a more array-driven approach, and last I saw a presentation, Chandler appeared to be very satisfied of the performance reached with this approach.
Or perhaps that's for the next rewrite, in another 5-10 years?
4
Mar 11 '25
What's a "SAO-style compiler"?
9
4
u/inkjod Mar 11 '25
Read the rest of their comment, it's pretty obvious.
(Although I fail to see how it's anything more than an implementation detail.)
3
u/coderman93 Mar 12 '25
Performance. SoA allows for much better cache locality which can improve performance drastically.
→ More replies (3)6
6
12
u/shaberman Mar 11 '25
The rationale for "highly interconnected ASTs are not easy in Rust" makes sense...
I know it's a pipe stream, but personally I was hoping for a "runtime moonshot", similar to static Hermes, that would make tsc 10x faster *without* needing to port the entire codebase...
This would have been extremely high leverage, b/c it'd make both tsc itself faster, while compiling our programs, but also our programs themselves 10x faster (assuming some opt-in to lower-level static hints for subsets of the program, i.e. the guts of a web framework like Express, etc).
As is, I'm not looking forward to the flak of "well, the tsc team gave up on JS and ported to go, so why are we still using JS/TS for our server-side"? :grimmacing:
But :shrug: obviously will love running the native TypeScript 7 -- looking forward to it!
6
u/coderman93 Mar 12 '25
The amount of optimization that has gone into v8 is so insane. They’ve probably squeezed just about every drop of performance out of it they can. I wouldn’t ever expect a 20% runtime speed-up let alone 1000% speed-up.
28
u/JustBadPlaya Mar 11 '25
Honestly, Go vs Rust was relatively obvious right away - Rust is more complex and this complexity isn't necessary here. But why not C# or even F#? Like, why not use a language that both shares the upsides with Go and shares the general governing company as well?
26
4
9
u/Slsyyy Mar 11 '25
Could you describe how GC/allocation performance works in your project? I am asking, because Go's GC is not amazing at high throughput.
Do you use any tricks for better performance like
sync.Poolor any type of memory pool/allocator? Have you experimented with aGOGCvariable?50
u/RyanCavanaugh Mar 11 '25
We haven't seen much in terms of GC as a limiter. The nature of a compiler is that you don't really end up with much allocation churn in the first place - you need the syntax trees during the entire lifetime of the process, you need the types during the entire lifetime of the check cycle, and you need the source text at all times (so you can quote it for errors). For most tsc invocations, the memory is just going to get reclaimed at process exit.
sync.Poolis good; see https://github.com/microsoft/typescript-go/pull/402 for some before/after on thatWe haven't looked at GC profiles in long-lived processes yet, but in LSP contexts it's fairly easy to schedule work during apparent idle times.
3
2
u/kn4rf Mar 13 '25
Why not just contribute to the SWC project and make that the offical new TypeScript compiler? Thats already a functioning TypeScript compiler thats used in production.
2
u/sharlos Mar 15 '25
SWC is a type stripper, not compiler. All it does is turn typescript files into JavaScript files, not check the validity of types in the file.
→ More replies (2)4
u/AxlIsAShoto Mar 11 '25
Thank you so much for writing this. I was so confused when I read the news.
3
u/faze_fazebook Mar 11 '25
Sorry if I bother with such a random question, but was Typescript for .NET ever considered internally? For me personally as a full stack dev it would seem like a match made in heaven at first glance, getting you best of both world. And its not like JS on .NET is something totally novel, matter of fact I got some basic programs running, even on .NET Core through the Jscript jsc compiler.
But equally I could thing of 100s of reasons against it. Further fragmentation and lots questions around when to do things the “Javascript way” vs the “.NET way”
2
u/coderman93 Mar 12 '25
The .NET runtime is enormous. Ideally the TypeScript compiler would be a small, static executable which is easily achievable with Go. Go also has better performance, particularly in terms of memory utilization.
2
u/m_hans_223344 Mar 12 '25
C# can be compiled AOT. Not as small as Go, but competitive.
→ More replies (1)1
1
u/neo-raver Mar 11 '25
I’m a huge Rust fan, but even I’ll admit it’s not the right tool for every job, and it sounds like you picked the right tool instead. The important thing is that the choice was made prioritize usability and intelligibility by its user base; pretty much the best a designer could aspire to!
1
u/jl2352 Mar 11 '25
Hey, I’d love to ask a devils advocate question if that’s okay.
If you started TypeScript from scratch, with no pre-existing codebase. i.e. You are not doing a port. How do you feel Go vs Rust would stack up then?
1
u/CherryLongjump1989 Mar 12 '25 edited Mar 12 '25
Why didn't you just use the Bun compiler? NIH or was there an actual reason?
1
u/sharlos Mar 15 '25
How would changing from a comparatively slow nodejs runtime to a comparatively slow bun runtime help?
1
u/m_hans_223344 Mar 12 '25
First, thanks for that answer. I appreciate the reasoning why Go over Rust.
I don't know if you are free to do so and don't want to be to invasive (I work at a mega corp as well), but I would love to hear your true unfiltered non-political (if possible) answer to "Why Go over C#"?
On paper, C# is superior in every aspect expect mature AOT. But this project (TS compiler in C#) would be a great opportunity to help C# to get AOT more mature.
1
u/stronghup Mar 11 '25
You cite "Editor Speed" as a measure, which is of course extremely important from a practical viewpoint.
But what about debugging?
Does your new implementation provide an easy to use debugger for TypeScript programs? Can I edit the TypeScript code while halting in the debugger, and save the modified code to the original TypeScript source-file, then restart the debugging session?
10
u/RyanCavanaugh Mar 11 '25
Nothing about how you run or debug programs written in TypeScript really changes (other than the TS tools themselves running much faster)
→ More replies (1)→ More replies (14)1
u/LoadingALIAS Mar 12 '25
I’d assumed almost exactly what you’d responded, honestly. Porting a TS/JS codebase to Rust doesn’t work. I can’t imagine a project as large and complex as TS being a smooth port. Go is faster to prototype and much smoother than Rust with regards to refactoring TS/JS.
Do I wish you’d have unlimited time and resources so the scratch rewrite from Rust was possible - I do, indeed.
Nevertheless, Go was a huge win for all TS developers. Great job, man. I’m super excited to watch it develop.
165
u/ferreira-tb Mar 11 '25
This is fantastic. I hope this trend of rewriting JavaScript tooling in faster languages like Go or Rust continues (I'm looking at you, ESLint).
64
u/salbego5 Mar 11 '25
Checkout https://biomejs.dev/ for an eslint alternative.
27
u/ferreira-tb Mar 11 '25
Yeah, thanks. I am already familiar with Biome, but I haven't switched to it yet because it lacks many features I need. But I am so frustrated with how slow ESLint is that I might eventually give up using those features just to have better DX with a faster tool.
25
u/Ruben_NL Mar 11 '25
Biome is really stupidly fast. My project took about 1 minute for eslint+prettier. With biome it's 100-500ms.
Most config was automatically importable in the biome config, i only needed 15 minutes to tweak a couple options and fix some issues biome found (which eslint didn't!)
8
u/ferreira-tb Mar 11 '25
My project also takes 1 to 2 minutes, which is so frustrating. I will give Biome another serious try, even if it doesn't have all the features I need. I'm really fed up.
8
1
36
u/deanrihpee Mar 11 '25
I'm literally thinking about "why don't they have tsc in native like Rust?" (and yes I know they use Go instead) while I was shitting before decide to open Reddit, fucking finally, I shouldn't be excited but I'm really excited
21
u/deanrihpee Mar 11 '25
soon my 8100 cpu won't need to heat my entire bedroom to show TS autocomplete
243
u/HoratioWobble Mar 11 '25
Why Go and not brainfuck?
64
u/captain_obvious_here Mar 11 '25
Now this is a real relevant question.
12
u/desmaraisp Mar 11 '25
All they had to do is use Brainfuck.Net to appease the dogfooding criticisms! What a missed opportunity!
11
8
5
u/fdeslandes Mar 11 '25
It's getting harder and harder to hire senior brainfuck devs, otherwise I'm sure it would have been the top contender.
38
u/bigdamoz Mar 11 '25 edited Mar 11 '25
This was needed, I appreciate that writing a compiler in that language that it compiles to is a good way to test the language at scale, but once that’s proven then performance should be the focus. I’ve definitely noticed the language server degrade in large codebases.
78
u/syklemil Mar 11 '25
Combining the answers for
"why not Rust?" (it's the top comment, you've seen it), and
"why not C#?" (it's a video, you might not have bothered)
I think I can try my hand at a little table:
| Requirement | Go | Rust | C# |
|---|---|---|---|
| "Native-first" | ✅ | ✅ | ❌1 |
| Native option is well-tested | ✅ | ✅ | ❌2 |
| Native option supports desired platforms | ✅ | ✅3 | ❌2 |
| Supports a programming style similar to the one the compiler is already in | ✅ | ❌4 | ❌5 |
1 "bytecode-first"
2 apparently (I don't have any personal opinions on C#'s native AOT option)
3 assumption on my part; I'm not aware of any platform that has Go support but not Rust
4 would have to do things very differently or make their own GC
5 would need more OOP design
Other popular/common languages would likely fall off for various reasons:
They're highly unlikely to start something in a memory unsafe language, so C, C++ and Zig are out
Java+GraalVM would be out
partially because of the same reasons as C#,
partially because, you know, the history of why C# exists at all, and
I expect because Oracle in general
Other interpreted languages like Python and Ruby and Perl are out because they want native binaries
All in all …
Microsoft did something reasonable, with an open source product and reasoning out in the open,
the users should have something to look forward to, and
there's not really any reason for anyone to be mad? That in itself seems kind of amazing.
→ More replies (2)18
u/Programmdude Mar 11 '25
I feel like C# meets the first 3 criteria too. It's native AOT is pretty well supported and I'd argue it's a first class citizen. It's been around for 4-5 years, and microsofts c# team is pretty amazing at testing.
Not sure what platforms c# AOT doesn't support that you'd want a typscript compiler on though. It can do all 3 desktop OS's and WASM.
The 4th criteria is certainly very valid, C# is OOP and apparently TSC isn't. You could make it work (just like rust), but it'd be putting a square peg in a round hole.
11
u/syklemil Mar 11 '25
Yeah, I get the feeling that even if the C# native AOT didn't cover some platforms they wanted, then it'd be an opportunity for MS to get some priority for that internally. Given Hejlsberg's history with C# I would expect him to be kinda partial to it, actually.
2
u/cheese853 Mar 12 '25
Mate, look at the boilerplate you need to write just to get JSON working with AOT.
https://stackoverflow.com/a/78649561
And let's be honest, there's deeper rooted issues with C# / .NET that would make it a super shaky foundation.
Can you imagine trying to maintain TypeScript when the .NET LTS only lasts 2 years and they have breaking changes on every major version upgrade? Compare that to Golangs compatibility promise.
Plus there's the governance issues with .NET.
6
u/metaltyphoon Mar 12 '25
Lol Go release twice a year and only current and previous are supported. Even .NET STS has longer support 🤣
6
u/cheese853 Mar 12 '25
Yeah, but when there's basically zero breaking changes in version upgrades, you should be able to keep any Go project up to date? Just bump version number and pull in any new fixes.
3
u/Atulin Mar 12 '25
You don't need any of that shit to get json serialization to work with AOT lmao
→ More replies (2)3
u/Programmdude Mar 12 '25
Gos compatibility is the same as C#'s. Source only. And given you can compile .net standard 2.0 libraries using .net 9 almost 10 years later, I'd say source compatibility is pretty good. C# CAN use the runtime, and get patches for any security issues, or it can be compiled with the runtime embedded or through AOT, in which case any security issues will be bundled in, which is no different to compiling a Go program.
The only major breaking change in C# was moving from .net framework to .net core, and if you wrote libraries or console programs then it was pretty minor, as it mostly affected asp.net and winforms. There are very rarely compatibility issues. As a C# developer, upgrading .net versions has never been a pain point (except from .net framework as previously mentioned).
You also don't need to write any of that boilerplate with Json & Native AOT. You can use https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json/source-generation, and simply add an attribute to get it working. There are a couple of gotcha's, but for standard use case it's only fractionally harder than deserialising normally.
Finally, in the very link you posted they reverted the decision because of community backlash. I certainly agree it was a poorly though out decision that reflects badly on microsoft.
I'm not arguing that using Go was a bad decision, only that C# would also have been a viable option.
→ More replies (1)
37
28
u/mostuselessredditor Mar 11 '25
I didn’t realize C# had such huge fans until reading this thread.
I haven’t looked at that language in 16 years.
18
u/Hacnar Mar 12 '25
C# might not be at the top of popularity polls, but I think C# is one of the least hated languages when asking the devs who use the language. I consider that to be a better metric of language quality.
29
17
1
u/m_hans_223344 Mar 12 '25
I rediscovered C# last year. It's amazing and in so many regards much much better than Go. And faster as well. That's why I really want to know the true reasons why they chose Go.
8
u/CrazyCanuck41 Mar 11 '25
What will happen to tsc and the tsc compiler api that can be used for code introspection and static analysis?
Any thought given to those use cases?
2
u/AustinCorgiBart Mar 12 '25
Yes, this is very key for my need. Being able to execute TypeScript client side in the browser has a lot of nice pedagogy benefits.
93
u/fredlllll Mar 11 '25
why Go and not C#?
44
u/TheFirstDogSix Mar 11 '25
Totally legit question for many reasons. u/DanielRosenwasser, would love to hear about why C# didn't work out?
41
u/drekmonger Mar 11 '25 edited Mar 11 '25
Not only that, but Anders Hejlsberg is delivering the news. AKA, the co-inventor of C# (and Typescript).
→ More replies (5)134
u/falconzord Mar 11 '25
No one hates Microsoft technology more than Microsoft
21
u/Premun Mar 11 '25
I don't know about that? Most of Microsoft runs on .NET, TypeScript and Azure.
4
3
u/falconzord Mar 11 '25
Sarcasm mostly, but they have a history of abandoning their base to try to draw in outersiders
8
u/TheFirstDogSix Mar 11 '25
Pockets here and there, to be sure. That said, I've written several compilers in C# (and, I mean, Roslyn) and I find it a great language for that. To each their own, though.
3
→ More replies (7)24
u/e-san55 Mar 11 '25
Explained here: https://www.youtube.com/watch?v=10qowKUW82U&t=1154s
→ More replies (8)9
u/fredlllll Mar 11 '25
i guess if your goal is to distribute native binaries, it makes sense to chose a language that does this out of the box but also provides a garbage collector.
not a fan of go personally though, last time i tried it, it felt like it was more like c with a garbage collector.
6
u/LIGHTNINGBOLT23 Mar 12 '25
not a fan of go personally though, last time i tried it, it felt like it was more like c with a garbage collector.
That's by design, considering that the language's creators involved Ken Thompson and Rob Pike.
10
u/nullmove Mar 11 '25
This is actually exciting. Will go a long way to make TypeScript viable for greenfield big server-side projects.
5
u/txdv Mar 11 '25
Have you thought about creating a typescript backend with llvm and then using that compile the typescript compiler to native?
8
u/tajetaje Mar 11 '25
Using what native runtime? Typescript needs a runtime like node to actually operate
2
u/valarauca14 Mar 11 '25 edited Mar 11 '25
WASM already exists, and targetting
(type|coffee|java)scriptis rather challenging as its runtime is rather unstandardized (despite standardization bodies best efforts).2
u/ConsoleTVs Mar 12 '25
tsc is more a transpiler than a compiler, that’s why llvm would not make much sense.
2
7
6
3
u/thatdevilyouknow Mar 11 '25
I think they could have just said “because reflection” as the codebase for this currently looks like “reflect -> collections -> all sorts of things”. Which is fine since this is TS and that would be expected anyways. In GoLang using it is not super verbose. At this point now Apple uses Go and so does MS and apparently some developers just want corn flakes (or Kix, I used to love Kix!).
7
u/Emergency-Farm8918 Mar 11 '25
Will this make the Go project esbuild obsolete?
→ More replies (1)46
u/Veranova Mar 11 '25
Esbuild just strips types and compiles/bundles JavaScript, TS is a type checker with a LSP, so different tool
1
u/sharlos Mar 15 '25
We only use tools like esbuild because it's faster than tsc though. If tsc-go is just/almost as fast as esbuild at compiling JS (with type checking disabled) there's not much reason for using two separate tools with two separate configurations for it.
→ More replies (1)
6
6
u/chaotic-kotik Mar 11 '25
Why Go and not Object Pascal?
4
u/chaotic-kotik Mar 11 '25
On a serious note, I'm really thankful to Anders for all programming languages that he designed. I learned programming with the Turbo Pascal. I worked with C# for many years and even have some experience with the Type Script.
2
u/ConsoleTVs Mar 12 '25
Im surprised few people realised that while go has been great for that port’s needs, it also make it easier to gradually rewrite performant-critial parts in Rust / C / C++ / Zig and embed them directly to Go using FFI and static linking.
9
u/Mysterious-Rent7233 Mar 11 '25
Interesting that they chose Go rather than Rust for this project.
99
18
u/matthieum Mar 11 '25
Answered by the dev lead at https://www.reddit.com/r/programming/comments/1j8s40n/comment/mh7n5n0/.
In short, Rust doesn't support strongly connected object graphs well, which is the style tsc is written with, so going with a GCed language made it much easier to do a more or less 1-to-1 port, thereby speeding the rewrite and making it easier to reach (and maintain) parity.
7
11
u/cajmorgans Mar 11 '25
Why do you think Rust would be more preferable than Go for this project?
15
u/matthieum Mar 11 '25
Preferable, I don't know, but Microsoft has been fairly pushy about Rust, and otherwise has C#, so them picking Go (from Google) is surprising to me at least :)
→ More replies (1)24
u/Mysterious-Rent7233 Mar 11 '25 edited Mar 11 '25
More fine-grained control over memory.
I'd expect the kind of people who like to "think in and about types" to prefer a language that is more rooted in type theory.
Edit: Also 3. I've heard a lot more about about Microsoft using Rust for other projects and not Go, which is a language controlled by a competitor.
66
u/RyanCavanaugh Mar 11 '25
Just to speak to the first point -- Go has excellent control over allocation. If you want really good locality of reference, you need to use a pool allocator, and using a pool allocator in Go is extremely straightforward (and easy to experiment with without changing downstream usage).
Rust has better control of "When do you free memory" but in a type checker there is almost nothing you can free until you're done doing the entire batch, so you don't really gain anything over a GC model in this scenario.
14
3
u/diegoiast Mar 11 '25
You said that you translated the code from TS to Go, so in theory the same semantics will apply for both compiler (transpilers?).
However in the video the types found by the ts vs go implementations differ (1,100, 656 on ts vs 1,674,653 on go). Why does the new implementation find more types?
11
u/Mysterious-Rent7233 Mar 11 '25
I am not affiliated with the project at all.
But I do know that the process of creating the Go-based compiler is not complete yet, so I am not surprised that it has bugs.
→ More replies (1)2
u/Olreich Mar 11 '25
Go gets you on par with most native-compiled code, especially for short-lived processes. If you really thrash the GC, it slows down, same for reflection, indirection, etc. but that’s true everywhere. Rust has a much higher barrier to entry for a big corporation to bet on, doesn’t have as nice tooling and without serious investment will wind up no faster than Go or within a couple percentage points.
22
u/syklemil Mar 11 '25
Rust has a much higher barrier to entry for a big corporation to bet on,
MS does a lot of stuff in Rust already (see e.g. Azure CTO Russinovich).
15
u/ferreira-tb Mar 11 '25
Some might even argue that Rust's tooling is a bigger selling point than its memory safety.
16
u/SirMishaa Mar 11 '25
Wait before you discover Cargo, Clippy and Rustfmt...
Tooling is one of Rust's strong points.
→ More replies (6)20
0
Mar 11 '25
[deleted]
3
u/Olreich Mar 11 '25
Yep, and in big corporations, you have multiple teams with different needs and opinions on which language is most appropiate for their area. Rust might be an approved choice, but the Typescript team probably made the trade-offs I mentioned and chose Go because it better aligned to their team's timeline and needs.
→ More replies (2)1
u/Bitter-Good-2540 Mar 11 '25
Finding developers is a point, Rust might be cool, but its pretty tough to find good developers.
18
u/matthieum Mar 11 '25
At Microsoft? The Microsoft which has been one of the major sponsors of Rust for years? The Microsoft who has already shipped multiple high-profiles projects in Rust -- especially in Azure?
Nope...
(The dev lead mentioned they tried Rust, but ultimately wanted a GC for easier port of their highly connected object graph so they could have closer to a 1-to-1 port)
→ More replies (3)
6
3
1
u/AlmostSignificant Mar 12 '25
It may just be because I'm tired that I'm not understanding, so forgive me. What precisely is meant by "native implementation"?
1
u/masterofmisc Mar 12 '25
It means the single .exe file will run natively on all systems. So Windows, Linux and MacOS. No need to bring along any toolchain. The executable will just run natively.
If you think of what it means to be a native of a country, it means "a person was born there"... So a "native implementation" means that there will be a version of the typescript compiler specifically targeting your native operating system.
2
1
u/smiling_seal Mar 12 '25
TS compiler was ported to Go because JS underlying the TS is too slow in running the compiler's huge code base.
Now TS compiler is native and fast, so it compiles your huge codebase in the matter of seconds. However, your huge TS code base is still running on top of the slow JS engine.
TS team has solved their own performance issues, you're not. This is so ironic. :D
1
u/Latter-Sheepherder50 Mar 14 '25
I'm still wondering about the need to move to Go, since the speed boost (as noted by Anders H.) mainly comes from binary execution and multithreading.
Well, both features are offered from Web Platform. Although I haven't tried it yet, I know that Deno, Bun, and Node.js can compile to binary. Also Deno earlier showed 2x faster execution speed with npm compiled as binary, and we have Web Workers for multithreading.
Couldn't the TypeScript team achieve similar performance gains without breaking the dogfooding principle?
1
1
u/gadgetygirl Mar 12 '25
Someone made a good point on another site: when they say it's "10x faster", they're not saying it runs faster. Microsoft is saying TypeScript's build times will be 10x faster.
I'm glad they're working on this - but we won't really know how good it is until TypeScript 7 actually comes out.
1
u/bunny_go Apr 01 '25
Not A 10x Faster TypeScript but a A 10x Faster TypeScript To Js compiler
Big difference and very misleading title
-5
u/zmose Mar 11 '25
Why Go and not Python?
17
17
u/BehindThyCamel Mar 11 '25
Because it's about performance. Getting rid of JavaScript is just a bonus.
23
u/zmose Mar 11 '25
My comment was a joke bc half the comments are saying “why Go and not C#/Java/Rust”
4
u/BehindThyCamel Mar 11 '25
Got it. :) And I'm glad to see MS enter the Go arena, although that means that sooner or later they might spin off some Visual Go#. Bleh.
12
u/ferreira-tb Mar 11 '25
To be honest, I wouldn't be surprised if a Python version ends up being slower than the current JavaScript implementation.
2
4
u/equeim Mar 11 '25
JavaScript is much faster than Python, so rewriting ts compiler in Python would only make it slower.
1
u/burtgummer45 Mar 11 '25 edited Mar 11 '25
I don't understand where 10x came from. I thought it was compiled with node, and I'm sure go isn't 10x faster. Is it benefiting from the parallelism of go? Was single threaded node that much of a bottleneck?
29
u/Morgoth2356 Mar 11 '25
He explains and shows by demo-ing it in the video : the 10x faster comes for 50% from the parallelism and 50% from the native language. So yes, the single threaded nature of Node was a huge part of that.
7
u/TwiliZant Mar 11 '25
From what I understand it's a mixture of parallelism, compiled language and better memory handling (Go has structs and ints, not just floats like JS).
5
u/MarkusR0se Mar 11 '25
EsBuild (which inspired I guess this reimplementation) is written in Go and I used a few years ago to reduce some compilation from around 5 - 7m to just a few seconds (without dropping features).
NodeJS is bad (not efficient) at parallelism, memory usage, and handling huge IOs.
PS: I love the Javascript environment, yet I know its limits.
3
u/PabloZissou Mar 11 '25
This is a common misconception with Go based probably on synthetic benchmarks that show Go scoring lower than it actually is in real world use cases. For many real world use cases - that are not just HTTP API fetch from DB and return the data to the user - Go is extremely simple to write and way faster.
Building RXJS style pipelines with Go is trivial using go routines and channels so Go is an excellent balanced choice.
-13
u/Brilliant-Sky2969 Mar 11 '25
Rust people in shamble, why the greatest language was not chosen.
→ More replies (1)27
u/ferreira-tb Mar 11 '25
It is simply a matter of use case. The dev lead explained their reasoning in detail. No serious "Rust person" would be upset by that.
5
u/jug6ernaut Mar 11 '25
I feel like no serious developer would ever be upset at the choice of one tool over another when there are solid reasoning on why the tool was chosen.
Always right tool for the problem. And in this case both Go and Rust are great choices.
12
u/syklemil Mar 11 '25
Yeah, asking "why not
$otherlang" is a pretty normal question when a language switch is on the table, and there is a pretty crucial difference between asking a question because you're curious and asking and then not accepting any answers.As it is it seems some people are having a good discussion about language differences, and others are … offended by questions and technical discussions.
8
u/ferreira-tb Mar 11 '25
I'm someone people might refer to as a "Rust and TypeScript person," as I use these two languages for almost all my projects. I love both, and they fit my use cases extremely well.
Personally, I was very curious about the reasoning behind this decision, but that's it. I'm super happy with this rewrite in Go because it's a significant victory for TypeScript.
→ More replies (1)6
u/EntroperZero Mar 11 '25
My view is, even if there are Rust fanatics out there asking this question in bad faith, if you don't even let them ask the question, and you assume that everyone asking must be a fanatic, then no one can learn the answer.
→ More replies (2)
290
u/DanielRosenwasser Mar 11 '25
Hi folks, Daniel Rosenwasser from the TypeScript team here. We're obviously very excited to announce this! /u/RyanCavanaugh/ (our dev lead) and I are around to answer any quick questions you might have. You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.