As in: there&#x27;s no allocation&#x2F;deallocation code. The code relies on garbage collection to function.

&gt; The TypeScript compiler relies on garbage collection in multiple placesWhat? And how? And how would that help in Go which has a completely different garbage collection mechanism?

Especially given Anders is the one announcing this, given he was the chief architect of C#. But C# AOT is maybe not as mature&#x2F;lightweight as a Go binary and clearly startup time here is very important. [Edit: the real reason is in the FAQ posted in a bunch of other comments <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411</a>]

he went into the C# question in more detail this interview: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;10qowKUW82U?t=1154s" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;10qowKUW82U?t=1154s</a>

&gt; I was very surprised to see that the TypeScript team didn’t choose RustTypescript is a Microsoft project, right? I’m surprised they didn’t choose C#.

Which is a massive pro for any open source project

Is learning a language even a thing anymore with $Internal_or_external_LLM_helper plugin available for every IDE? I haven&#x27;t found syntax lookups to be that much a concern anymore and any boneheaded LLM suggestions are trivial to detect&#x2F;fix.

imho Go is a far easier language to learn than Rust, so it lowers the barrier to entry for new contributors.

I love Rust, but you can play exactly the same game with Rust: <a href="https:&#x2F;&#x2F;github.com&#x2F;Speykious&#x2F;cve-rs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Speykious&#x2F;cve-rs</a>

This is true in that if you pass pointers through go routines, you do not have guarantees about what’s at the end of that pointer. However, this is “by design” in that generally you shouldn’t do that; the overhead the go memory model places on developers is to remember what’s passed as value and what’s passed as a pointer, and act accordingly. The rest it takes care of for you.The burden placed by rust on the developer is to keep track of all possible mutability and readability states and commit to them upfront during development. (If I may summarize, been a long time since I wrote any Rust). The rest it takes care of for you.The question of which a developer prefers at a certain skill level, and which a manager of developers at a certain skill level prefers, is going to vary.

That is not a violation of memory safety, that&#x27;s a violation of concurrency safety, which Go doesn&#x27;t promise (and of course, Rust does.)

&quot;Memory safety&quot; is a term of art meaning susceptibility to memory corruption attacks. They had to come up with some name for it; that&#x27;s the name they came up with. This is a perennial tangent in conversations among technologists: give something a legible name, and people will try to axiomatically (re)define it.Rust is memory safe. Go is memory safe. Python is memory safe. Typescript is memory safe. C++ is not memory safe. C is not memory safe.

&gt; Go and Rust are both memory safe.Go doesn&#x27;t seem to be memory safe, see <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;wbejky&#x2F;comment&#x2F;ii7ak8m&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;comments&#x2F;wbejky&#x2F;comment&#x2F;ii7ak8...</a> and <a href="https:&#x2F;&#x2F;go.dev&#x2F;play&#x2F;p&#x2F;3PBAfWkSue3" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;play&#x2F;p&#x2F;3PBAfWkSue3</a>

I&#x27;m confused what you ascribe to as undefined behaviour. What does that mean in the Go context? There is no mention of what UB is in Go at <a href="https:&#x2F;&#x2F;go.dev&#x2F;ref&#x2F;spec" rel="nofollow">https:&#x2F;&#x2F;go.dev&#x2F;ref&#x2F;spec</a> .

A tiny thing that&#x27;s not relevant to this particular piece of work but is worth having in background when thinking about Go is that while Go would like Python typically be described as &quot;memory safe&quot; unlike Java (or more remarkably, Rust) it is very possible for naive programmers to cause undefined behaviour in this language without realising it.Specifically if you race any non-trivial Go object (say, a hash table, or a string) then that&#x27;s immediately UB. Internally what&#x27;s happening is that these objects have internal consistency rules which you can easily break this way and they&#x27;re not protected against that because the trivial way to do so is expensive. Writing a Go data race isn&#x27;t as trivial as writing a use-after-free in C++ but it&#x27;s not actually difficult to do by mistake.In single threaded software this is no caveat at all, but most large software these days does have some threading involved.

yes, this will definitely vastly increase the Doom fps, haha (I’m the guy that did that project). But I think there’s a lot more to it than that.tl;dr — Rust would be great for a rewrite, but Go makes way more sense for a port. After the dust settles, I hope people focus on the outcomes, not the language choice.I was very surprised to see that the TypeScript team didn’t choose Rust, not just because it seemed like an obvious technical choice but because the whole ecosystem is clearly converging on Rust _right now_ and has been for a while. I write Rust for my day job and I absolutely love Rust. TypeScript will always have such a special place in my heart but for years now, when I can use Rust.. I use Rust. But it makes a lot of sense to pick Go.The key “reading between the lines” from the announcement is that they’re doing a port not a rewrite. That’s a very big difference on a complex project with 100-man-years poured into it.Places where Go is a better fit than Rust when porting JavaScript:- Go, like JavaScript and unlike Rust, is garbage collected. The TypeScript compiler relies on garbage collection in multiple places, and there are probably more that do but no one realizes it. It would be dangerous and very risky to attempt to unwind all of that. If it were a Rust rewrite, this problem goes away, but they’re not doing a rewrite.- Rust is so stupidly hard. I repeat, I love Rust. Love it. But damn. Sometimes it feels like the Rust language actively makes decisions that demolish the DX of the 99.99% use-case if there’s a 0.001% use-case that would be slightly more correct. Go is such a dream compared to Rust in this respect. I know people that more-or-less learned Go in a weekend and are writing it professionally daily. I also know people that have been writing Rust every day professionally for years and say they still feel like noobs. It’s undeniable what a difference this makes on productivity for some teams.Places where Go is just as good a fit as Rust:- Go and Rust both have great parallelism&#x2F;concurrency support. Go supports both shared memory (with explicit synchronization) and message-passing concurrency (via goroutines &amp; channels). In JavaScript, multi-threading requires IPC with WebWorkers, making Go’s concurrency model a smoother fit for porting a JS-heavy codebase that assumes implicit shared state. Rust enforces strict ownership rules that disallows shared state, or we can at least say makes it a lot harder (by design, admittedly).- Go and Rust both have great tooling. Sure, there are so many Rust JavaScript tools, but esbuild definitively proves that Go tooling can work. Heck, the TypeScript project itself uses esbuild today.- Go and Rust are both memory safe.- Go and Rust have lots of “zero (or near zero) cost abstractions” in their language surface. The current TypeScript compiler codebase makes great use of TypeScript enums for bit fiddling and packing boolean flags into a single int32. It sucks to deal with (especially with a Node debugger attached to the TypeScript typechecker). While Go structs are not literally zero cost, they’re going to be SO MUCH nicer than JavaScript objects for a use-case like this that’s so common in the current codebase. I think Rust sorta wins when it comes to plentiful abstractions, but Go has more than enough to make a huge impact.Places where Rust wins:- the Rust type system. no contest. In fairness, Go doesn’t try to have a fancy type system. It makes up for a lot of the DX I complained about above. When you get an error that something won’t compile, but only when targeting Windows because Rust understands the difference in file permissions… wow. But clearly, what Go has is good enough.- so many new tools (basically, all of them that are not also in JS) are being done in Rust now. The alignment on this would have been cool. But hey, maybe this will force the bindings to be high-quality which benefits lots of other languages too (Zig type emitter, anyone?!).By this time next week when the shock wears off, I just really hope what people focus on is that our TypeScript type checking is about to get 10 times faster. That’s such a big deal. I can’t even put it into words. I hope the TypeScript team is ready to be bombarded by people trying to use this TODAY despite them saying it’s just a preview, because there are some companies that are absolutely desperate to improve their editor perf and un-bottleneck their CI. I hope people recognize what a big move this is by the TypeScript team to set the project up for success for the next dozen years. Fully ejecting from being a self-hosted language is a BIG and unprecedented move!

thank you, to both of you, for so many years of groundbreaking work.  you&#x27;ve both been on the project for, what, 11 years now?  such legends.

I&#x27;d be curious to hear about the politics and behinds the scenes of this project. How did you get buy-in? What were some of the sticking points in getting this project off of the ground? When you mention that many other languages were used to spike the new compiler, were there interesting learnings?

Honestly, the choice seems fine to me: the vast majority of users are not compiling huge TypeScript projects in the browser. If you&#x27;re using Vite&#x2F;ESBuild, you&#x27;re already using a Go-based JS toolchain, and last I checked Vite was pretty darn popular. I don&#x27;t suspect there will be a huge burden for things like playground; given the general performance uplift that the Go tsc implementation already gets, it may in fact be faster even after paying the Wasm tax. (And even if it isn&#x27;t, it should be more than fine for playground anyways.)

I feel like you&#x27;ll need to provide a wasm binary for browser environments and maybe as a fallback in node itself. Last time I checked, Go really struggles to perform when targeting wasm. This might be the only reason I&#x27;d like to see it in Rust but I&#x27;m still glad you went with Go.Are there any insights on the platform decision?

Not involved, but there&#x27;s a faq in their repo, and this answers your question, perhaps, a bit: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411</a>

There is an interview with Anders Hejlsberg here: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZlGza4oIleY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZlGza4oIleY</a>The question comes up and he quickly glosses over it, but by the sound of it he isn&#x27;t impressed with the performance or support of AOT compiled C# on all targeted platforms.

I&#x27;m not involved in the decisions, but don&#x27;t C# applications have a higher startup time and memory usage? These are important considerations for a compiler like this that needs to start up and run fast in e.g. new CI&#x2F;CD boxes.For a daemon like an LSP I reckon C# would&#x27;ve worked.

Seeing that Hejlsberg started out with Turbo Pascal and Delphi, and that Go also has a lot of Pascal-family heritage, he might hold some sympathy for Go as well...

Anders explained his reasoning in this interview (transcript):<a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411#discussioncomment-12464695" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411#d...</a>

Why not AOT compiled C#, given the team&#x27;s historical background?

Daniel, please make this a priority. Post the Q&amp;A transcript to GitHub, at least.

&gt; You can also tune in to the Discord AMA mentioned in the blog this upcoming Thursday.Will the questions and answers be posted anywhere outside of Discord after it&#x27;s concluded?

We anticipate that we will eventually get a playground working on the new native codebase. We know we&#x27;ll likely compile down to WebAssembly, but a lot of how it gets integrated will depend on what the API looks like. We&#x27;re currently giving a lot of thought to that, but we have good ideas. <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;455" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;455</a>

What is the forward paths available for efforts like the TS Playground under Typescript 7 (native)?One of the nice advantages of js is that it can run so many places. Will TypeScript still be able to enjoy that legacy going forward, or is native only what we should expect in 7+?

This is very exciting! I&#x27;m curious if this move eventually unlocks features that have been deemed too expensive&#x2F;slow so far, e.g. typing `ReactElement` more accurately, typing `TemplateStringsArray` etc

We&#x27;ll be working on an API that ideally can be used through any language - that would be our preferred means of consuming the new codebase.

Since the new tsc is written in go, will I be able to pull it into my go web server as a middleware to dynamically transpile ts?

pnp is still very cool, and it would be great if we can find a better API story that works well with pnp!

Hi Daniel! What&#x27;s your stance on support for yarn pnp?

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I&#x27;ll post the response below. <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411</a>.____Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript. We wrote multiple prototypes experimenting with different data representations in different languages, and did deep investigations into the approaches used by existing native TypeScript parsers like swc, oxc, and esbuild. To be clear, many languages would be suitable in a ground-up rewrite situation. Go did the best when considering multiple criteria that are particular to this situation, and it&#x27;s worth explaining a few of them.By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we&#x27;re undertaking this more as a port that maintains the existing behavior and critical optimizations we&#x27;ve built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.Go also offers excellent control of memory layout and allocation (both on an object and field level) without requiring that the entire codebase continually concern itself with memory management. While this implies a garbage collector, the downsides of a GC aren&#x27;t particularly salient in our codebase. We don&#x27;t have any strong latency constraints that would suffer from GC pauses&#x2F;slowdowns. Batch compilations can effectively forego garbage collection entirely, since the process terminates at the end. In non-batch scenarios, most of our up-front allocations (ASTs, etc.) live for the entire life of the program, and we have strong domain information about when &quot;logical&quot; times to run the GC will be. Go&#x27;s model therefore nets us a very big win in reducing codebase complexity, while paying very little actual runtime cost for garbage collection.We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code.Acknowledging some weak spots, Go&#x27;s in-proc JS interop story is not as good as some of its alternatives. We have upcoming plans to mitigate this, and are committed to offering a performant and ergonomic JS API. We&#x27;ve been constrained in certain possible optimizations due to the current API model where consumers can access (or worse, modify) practically anything, and want to ensure that the new codebase keeps the door open for more freedom to change internal representations without having to worry about breaking all API users. Moving to a more intentional API design that also takes interop into account will let us move the ecosystem forward while still delivering these huge performance wins.

| with no frills.People say this like it&#x27;s a bad thing. It&#x27;s not, it&#x27;s Go&#x27;s primary strength.

Like others I&#x27;m curious about the choice of technology here. I see you went with Go, which is great! I know Go is fast! But its also a more &#x27;primitive&#x27; language (for lack of a better way of putting it) with no frills.Why not something like Rust? Most of the JS ecosystem that is moving toward faster tools seem to be going straight to Rust (Rolldown, rspack (the webpack successor) SWC, OXC, Lightning CSS &#x2F; Parcel etc) and one of the reasons given is it has really great language constructs for parsers and traversing ASTs (I think largely due to the existence of `match` but i&#x27;m not entirely sure)Was any thought given to this? And if so what was the deciding factors for Go vs something like Rust or another language entirely?

We are sure there will be a way to embed via something like WebAssembly, but the goal is to start from the IPC layer (similar to LSP), and then explore how possible it will be to integrate at a tighter level.

Golang is actually pretty easy to embed into JS&#x2F;TS via wasm. See esbuild.

Why embed it if you can run a process alongside yours and use efficient IPC? I suppose the compiler code should not be in some tight loop where an IPC boundary would be a noticeable slowdown. Compilation occurs relatively rarely, compared to running the compiled code, in things like Node &#x2F; Deno &#x2F; Bun &#x2F; Jupyter. LSPs use this model with a pretty wasteful XML IPC, and they don&#x27;t seem to feel slow.

Go has buildmode=c-shared, which compiles your program to a C-style shared library with C ABI exports. Any first call into your functions initializes the runtime transparently. It&#x27;s pretty seamless and automatic, and it&#x27;ll perform better than embedding a WASM engine.

Javascript is also quite difficult to embed in other applications. So not much has changed, except it&#x27;s no longer your language of choice.

Go is quite difficult to embed in other applications due to the runtime.What do you see as the future for use cases where the typescript compiler is embedded in other projects? (Eg. Deno, Jupyter kernels, etc.)There’s some talk of an inter process api, but vague hand waving here about technical details. What’s the vision?In TS7 will you be able to embed the compiler? Or is that not supported?

This might be an oddly specific question, but do you think performance improvements like this might eventually lead to features like partial type argument inference in generics? If I recall correctly off the top of my head, performance was one of the main reasons it was never implemented.

Please note that compilers and game engines have extremely different needs and performance characteristics—and also that statements like &quot;about 1.5x the performance of C++&quot; are virtually meaningless out-of-context. I feel we&#x27;ve long passed this type of performance discussion by and could do with more nuanced and specific discussions.

Sometimes, the time required to optimize is greater than the time required to rewrite.

What kind of C++ and what kind of JS?- C++ with thousands of tiny objects and virtual function calls?
- JavaScript where data is stored in large Int32Array and does operations on it like a VM?If you know anything about how JavaScript works, you know there is a lot of costly and challenging resource management.

Well-optimized JavaScript can, if you jump through hoops like avoiding object creation and storing your data in `Uint8Array`s. But idiomatic, maintainable JS simply can&#x27;t (except in microbenchmarks where allocations and memory layout aren&#x27;t yet concerns).In a game engine, you probably aren&#x27;t recreating every game object from frame to frame. But in a compiler, you&#x27;re creating new objects for every file you parse. That&#x27;s a huge amount of work for the GC.

I&#x27;m not sure how it is in Construct, but IME &quot;well-optimized&quot; JavaScript quickly becomes very difficult to read, debug, and update, because you&#x27;re relying heavily on runtime implementation quirks and micro-optimizations that make a hash of code cleanliness. Even you can hit close to native performance, the native equivalent usually has much more idiomatic code. The tsc team needs to balance performance of the compiler against keeping the codebase maintainable, which is especially vital for such a core piece of web infrastructure as TypeScript.

Our best estimate for how much faster the Go code is (in this situation) than the equivalent TS is ~3.5xIn a situation like a game engine I think 1.5x is reasonable, but TS has a huge amount of polymorphic data reading that defeats a lot of the optimizations in JS engines that get you to monomorphic property access speeds. If JS engines were better at monomorphizing access to common subtypes across different map shapes maybe it&#x27;d be closer, but no engine has implemented that or seems to have much appetite for doing so.

Why is the TypeScript team moving to an entirely different technologyA few things mentioned in an interview:Cannot build native binaries from TypeScriptCannot as easily take advantage of concurrency in TypeScriptWriting fast TypeScript requires you to write things in a way that isn&#x27;t &#x27;normal&#x27; idiomatic TypeScript. Easier to onboard new people onto a more idiomatic codebase.

&quot;Well optimized Javascript&quot;, and more generally, &quot;well-optimized code for a JIT&#x2F;optimizer for language X&quot;, is a subset of language X, is an undefined subset of language X, is a moving subset of language X that is moving in ways unrelated to your project, is actually multiple such subsets at a minimum one per JIT and arguably one per version of JIT compilers, and is generally a subset of language X that is extremely complicated (e.g., you can lose optimization if your arrays grow in certain ways, or you can non-locally deoptimize vast swathes of your code because one function call in one location happened to do one thing the JIT can&#x27;t handle and it had to despecialize everything touching it as a result) such that trying to keep a lot of developers in sync with the requirements on a large project is essentially infeasible.None of these things say &quot;this is a good way to build a large compiler suite that we&#x27;re building for performance&quot;.

Your JS code is way uglier than their Go code, if you&#x27;re doing those kinds of shenanigans.JS is 10x-100x slower than native languages (C++, Go, Rust, etc) if you write the code normally (i.e. don&#x27;t go down the road of uglifying your JS code to the point where it&#x27;s dramatically less pleasant to work with than the C++ code you&#x27;re comparing to).

While Go can be considered entirely different technology, I&#x27;d argue that Go is easy enough to understand for the vast majority of software developers that it&#x27;s not too difficult to learn.(disclaimer: I am a biased Go fan)

How does that scale with number of threads?

Are you comparing perfectly written JS to poorly written C++?

Who wants to spend all their time hand-tuning JS&#x2F;TS when you can write the same code in Go, spend no time at all optimizing it, and get 10x better results?

Well-optimized JS isn&#x27;t the only point of operation here. There&#x27;s a LOT of exchange, parsing and processing that interacts with the File System and the JS engine itself. It isn&#x27;t just a matter of loading a JS library and letting it do its thing. Every call that crosses the boundaries from JS runtime to the underlying host environment has a cost. This is multiplied across potentially many thousands of files.Just going from ESLint to Biome is more than a 10x improvement... it&#x27;s not just 1.5x because it&#x27;s not just the runtime logic at play for build tools.

It sounds like the C++ is not well-optimized then?

Does &quot;well-optimized JavaScript&quot; mean &quot;you can&#x27;t use Objects&quot;?In JavaScript, you can&#x27;t even put 8M keys in a Hashmap; inserts take &gt; 1 second per element:<a href="https:&#x2F;&#x2F;issues.chromium.org&#x2F;issues&#x2F;42202799" rel="nofollow">https:&#x2F;&#x2F;issues.chromium.org&#x2F;issues&#x2F;42202799</a>

Numeric code can, but compilers have to do a lot of string manipulation which is almost impossible to optimise well in JS.

Well-optimized JavaScript can get to within about 1.5x the performance of C++ - something we have experience with having developed a full game engine in JavaScript [1]. Why is the TypeScript team moving to an entirely different technology instead of working on optimizing the existing TS&#x2F;JS codebase?[1] <a href="https:&#x2F;&#x2F;www.construct.net&#x2F;en" rel="nofollow">https:&#x2F;&#x2F;www.construct.net&#x2F;en</a>

I write a lot of Go and a decent amount of TypeScript. Was there anything you found during this project that you found particularly helpful&#x2F;nice in Go, vs. TypeScript? Or was there anything about Go that increased the difficulty or required a change of approach?

Your patience with Michael Saboff is incredible.

Reading the article, it looks like they are writing go, so will probably be distributing go binaries.

I think they answered in their FAQ here: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;455#discussion-8063819" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;455#d...</a>.If I got it correctly, they created a node native module that allows synchronous communication on standard I&#x2F;O between external processes.So, this node module will make possible the communication between the typescript compiler GO process, that will expose an “API server compiler”, and a client side JavaScript process.They don’t think it will be possible to port all APIs and some&#x2F;most of them will be different than today.

Hey Daniel.I write a lot of tools that depend on the TypeScript compiler API, and they run in a lot of a lot of JS environments including Node and the browser. The current CJS codebase is even a little tricky to load into standard JS module supporting environments like browsers, so I&#x27;ve been _really_ looking forward to what Jake and others have said will be an upcoming standard modules based version.Is that still happening, and how will the native compiler be distributed for us tools authors? I presume WASM? Will the compiler API be compatible? Transforms, the AST, LanguageService, Program, SourceFile, Checker, etc.?I&#x27;m quite concerned that the migration path for tools could be extremely difficult.[edit] To add to this as I think about it: I maintain libraries that build on top of the TS API, and are then in turn used by other libraries that still access the TS APIs. Things like framework static analysis, then used by various linters, compilers, etc. Some linters are integrated with eslint via typescript-eslint. So the dependency chain is somewhat deep and wide.Is the path forward going to be that just the TS compiler has a JS interop layer and the rest stays the same, or are all TS ecosystem tools going to have to port to Go to run well?

I&#x27;m curious about the choice of Go to develop the new toolchain. Was the support for parallelism&#x2F;concurrency a factor in the decision?

Not sure if it does but the video linked in the post might answer your question? I think he is compiling vscode which includes Monaco editor which is where they are getting 10x faster stat. (I might be wrong here.) [0][0] <a href="https:&#x2F;&#x2F;youtu.be&#x2F;pNlq-EVld70?feature=shared&amp;t=112" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;pNlq-EVld70?feature=shared&amp;t=112</a>

Amazing news, but I&#x27;m wondering what will happen to Monaco editor and all the SaaS  that use typescript in the browser?

Daniel, congrats! I&#x27;m _so_ excited about everything y&#x27;all have achieved in the last few years.

Amazing!! I did not see timing. When might we see in VS Code? Edge?

I don&#x27;t think c or rust are really &#x27;closer to the metal&#x27; than golang (what they&#x27;re using)

Have you considered a closer to metal language to implement the compiler in like c or rust ? Have you evaluated further perf improvements ?

When can we just replace the JS runtime with TS and skip the compiler altogether? Start fresh, if you will.

Go is an extremely strange choice, given the ecosystem you&#x27;re targeting. I&#x27;ve got quite a bit of experience in it, TS, Rust and C++. I&#x27;d pick any of those for productivity and (in the case of C++ and Rust, thread-safety) over Go, simply because Go&#x27;s type system is so impoverished.From a performance perspective, I&#x27;d expect C++ and Rust to be much easier targets too, since I&#x27;ve seen quite a few industrial Go services be rewritten in C++&#x2F;Rust after they fail to meet runtime performance &#x2F; operability targets.Wasn&#x27;t there a recent study from Google that came to the same conclusion? (They see improved productivity for Go with junior programmers that don&#x27;t understand static typing, but then they can never actually stabilize the resulting codebase.)

Will we still have compiler plugins? What will this mean for projects like ts-patch?

It&#x27;s unlikely that you would get much performance benefit from AOT compiling a TypeScript codebase. (At least not with a ton of manual optimization of the native code, and if you&#x27;re going to do that, why not just rewrite in a native-first language?)JavaScript, like other dynamic languages, runs well with a JIT because the runtime can optimize for hotspots and common patterns (e.g. this method&#x27;s first argument is generally an object with this shape, so write a fast path for that case). In theory you could write an AOT compiler for TypeScript that made some of those inferences at compile time based on type definitions, but(a) nobody&#x27;s done that(b) it still wouldn&#x27;t be as fast as native, or much faster than JIT(c) it would be limited - any optimizations would die as soon as you used an inherently dynamic method like JSON.parse()

Thanks for answering questions.One thing I&#x27;m curious about: What about updating the original Typescript-based compiler to target WASM and&#x2F;or native code, without needing to run in a Javascript VM?Was that considered? What would (at a high level) the obstacles be to achieving similar performance to Golang?Edit: Clarified to show that I indicate updating the original compiler.

Is 10x a starting point or could we expect even more improvements in the future?

It was considered and tested, just not used in the end.

Discussion and video link here for anyone else interested: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411#discussioncomment-12463258" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411#d...</a>And lightly edited transcript here: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411#discussioncomment-12464695" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411#d...</a>

I am curious why dotnet was not considered - it should run everywhere Go does with added NativeAoT too, so I am especially curious given the folks involved ;)(FWIW, It must have been a very well thought out rationale.)Edit: watched the revenant clip from the GH discussion- makes sense. Maybe push NativeAoT to be as good?I am (positively) surprised Hejlsberg has not used this opportunity to push C#: a rarity in the software world where people never let go of their darlings. :)

Will the refactor possibly be an occasion for ironing out a spec

It’s fine, if it’s 2x faster after being feature complete, I don’t really mind. It still is a free speedup to all existing code-bases. Developers don’t need to anything than install the latest version of TypeScript I presume

&gt; While we’re not yet feature-completeThis is a big concern to me. Could you expand on what work is left to do for the native implementation of gsc? In particular, can you make an argument why that last bit of work won&#x27;t reduce these 10x figures we&#x27;re seeing? I&#x27;m worried the marketing got ahead of the engineering

Congrat on the announcement, this is a great achievement!

&gt; as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystemHave you considered the man-years and energy you&#x27;re making everyone waste? Just as an example, I wonder what the carbon footprint of ESLint has been over the years...Now, it pales in comparison to Python, but still...

Hi Daniel!Really interesting news, and uniquely dismaying to me as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystem.My question has to do with Ryan&#x27;s statement:&gt; We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScriptI&#x27;ve experimented deeply in this area (maybe 15k hours invested in BABLR so far) and what I&#x27;ve found is that it&#x27;s richly rewarding. Javascript is fast enough for what is needed, and its ability to cache on immutable data can make it lightning fast not through doing more work faster, but by making it possible to do less work. In other words, change the complexity class not the constant factor.Is this a direction you investigated? What made you decide to try to move sideways instead of forwards?

Not Daniel, but I&#x27;ve ported a typechecker from PHP to Rust (with some functional changes) and also tried working with the official Hack OCaml-based typechecker (a precursor to Flow).Rust and OCaml are _maybe_ prettier to look at, but for the average TypeScript developer Go is a much more understandable target IMO.Lifetimes and ownership are not trivial topics to grasp, and they add overhead (as discussed here: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411</a>) that not all contributors might grasp immediately.

This is awesome. Thanks to you and all the TypeScript team for the work they put on this project! Also, nice to see you here, engaging with the community.Porting to Go was the right decision, but part of me would&#x27;ve liked to see a different approach to solve the performance issue. Here I&#x27;m not thinking about the practicality, but simply about how cool it would&#x27;ve been if performance had instead been improved via:- porting to OCaml. I contributed to Flow once upon a time, and a version of TypeScript in OCaml would&#x27;ve been huge in unifying the efforts here.- porting to Rust. Having &quot;official&quot; TypeScript crates in rust would be huge for the Rust javascript-tooling ecosystem.- a new runtime (or compiler!). I&#x27;m thinking here an optional, stricter version of TypeScript that forbids all the dynamic behaviours that make JavaScript hard to optimize. I&#x27;m also imagining an interpreter or compiler that can then use this stricter TypeScript to run faster or produce an efficient native binary, skipping JavaScript altogether and using types for optimization.This last option would&#x27;ve been especially exciting since it is my opinion that Flow was hindered by the lack of dogfooding, at least when I was somewhat involved with the project. I hope this doesn&#x27;t happen in the TypeScript project.None of these are questions, just wanted to share these fanciful perspectives. I do agree Go sounds like the right choice, and and in any case I&#x27;m excited about the improvement in performance and memory usage. It really is the biggest gripe I have with TypeScript right now!

Does the mean the future toolset will be less reliant on NPM (etc)?Maybe I&#x27;m unique, but I prefer to not have the compiler tied up with a paryicular dependency-management&#x2F;library system.

Hi folks, Daniel Rosenwasser from the TypeScript team here. We&#x27;re obviously very excited to announce this! 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.

Are you looking for non-browser performance such as 3d? I see no case that another language is going to bring performance to the DOM. You&#x27;d have to be rendering straight to canvas&#x2F;webgl for me to believe any of this.

First, this thread and article have nothing to do with language and&#x2F;or application execution performance. It is only about the tsc compiler execution time.Second, JavaScript already executes quickly. Aside from arithmetic operations it has now reached performance parity to Java and highly optimized JavaScript (typed arrays and an understanding of data access from arrays and objects in memory) can come within 1.5x execution speed of C++. At this point all the slowness of JavaScript is related to things other than code execution, such as: garbage collection, unnecessary framework code bloat, and poorly written code.That being said it isn&#x27;t realistic to expect measurably significant faster execution times by replacing JavaScript with a WASM runtime. This is more true after considering that many performance problems with JavaScript in the wild are human problems more than technology problems.Third, WASM has nothing to do with JavaScript, according to its originators and maintainers. WASM was never created to compete, replace, modify, or influence JavaScript. WASM was created as a language ubiquitous Flash replacement in a sandbox. Since WASM executes in an agnostic sandbox the cost to replace an existing runtime is high since an existing run time is already available but a WASM runtime is more akin to installing a desktop application for first time run.

Ultimately the solution has to be breaking the browser monopoly on JS, via performance parity of WASM or some other route, so that developers can dogfood in performant languages instead across all their tooling, front end, and back end.

Our experience is the opposite, we have a pretty large flow typed code base, and can do a full check in &lt;100ms. When we converted to TS (decided not to merged) we saw typescript was in the multiple minute mark. It’s worth checking out LTI and how the typing on boundaries, enables flow to parallelize and give very precise error messages compared to TS. The third party lib support is however basically dead, except the latest versions of flow are starting to enable ingestion of TS types, so that’s interesting.

The issue with Flow is that it&#x27;s slow, flaky and has shifted the entire paradigm multiple times making version upgrades nearly impossible without also updating your dependencies, IF your dependencies adopted the new flow version as well. Otherwise you&#x27;re SOL.As a result the amount of libraries that ship flow types has absolutely dwindled over the years, and now typescript has completely taken over.

Interesting! This sounds like a surprisingly hard problem to me, from what I&#x27;ve seen of other infra teams.Does that mean more &quot;support rotations&quot; for TS compiler engineers on GitHub? Are there full-stack TS apps that the TS team owns that ownership can be spread around more? Will the TS team do more rotations onto other teams at MSFT?

Hey bcherny! Yes, dog-fooding (self-hosting) has definitely been a huge part in making TypeScript&#x27;s development experience as good as it is. The upside is the breadth of tests and infrastructure we&#x27;ve already put together to watch out for regressions. Still, to supplement this I think we will definitely be leaning a lot on developer feedback and will need to write more TypeScript that may not be in a compiler or language service codebase. :D

They should write a typescript-to-go transpiler (in typescript) , so that they can write their compiler in typescript and use typescript to transpile it to go.

Fast dev tools are awesome and I am glad the TS team is thinking deeply about dev experience, as always!One trade off is if the code for TS is no longer written in TS, that means the core team won’t be dogfooding TS day in and day out anymore, which might hurt devx in the long run. This is one of the failure modes that hurt Flow (written in OCaml), IMO. Curious how the team is thinking about this.

Ive been dreaming about this for years! Never been so pumped.

Thanks for the clarification. For those of us who don&#x27;t use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn&#x27;t know if it&#x27;s about a compiler or a runtime. What if they announced a bun competitor?<a href="https:&#x2F;&#x2F;betterstack.com&#x2F;community&#x2F;guides&#x2F;scaling-nodejs&#x2F;nodejs-vs-deno-vs-bun&#x2F;" rel="nofollow">https:&#x2F;&#x2F;betterstack.com&#x2F;community&#x2F;guides&#x2F;scaling-nodejs&#x2F;node...</a>.

If you have to explain why something is not ambiguous it is by definition ambiguous.

there is static hermes from Meta that do AoT compilation to native so I find it actually ambiguous. For a second I thought they did a compiler instead of transpile r.

“faster typescript” would also be a valid way to say the typescript compiler found a way to automatically write more performant javascript.Just like if you said faster C++ that could mean the compiler runs faster, or the resulting machine code runs faster.Just because the compile target is another human readable language doesn’t mean it ceases to be a typescript program.I didn’t think this particular example was very ambiguous because a general 10x speed up in the resulting JS would be insane, and I have used typescript enough to wish the compiler was faster. Though if we’re being pedantic, which I enjoy doing sometimes, I would say it is ambiguous.

&gt; It&#x27;s hard to tell if there will even be a runtime that somehow uses TS types to optimize even further.Yeah, that exists. AssemblyScript has an AOT compiler that generates binaries from statically typed code.

I use TS a lot and still assumed they are embarking on a native runtime&#x2F;compiler whatever epic journey.

Unfortunately many TS users have a surface level understanding of TS leading them to believe that TS is &quot;real&quot;

&gt; It&#x27;s hard to tell if there will even be a runtime that somehow uses TS types to optimize even furtherTypescript&#x27;s type system is unsound so it probably will never be very useful for an optimizing compiler. That was never the point of TS however.

To clarify why it&#x27;s actually not that ambiguous: TS is not (and does not have) a runtime at all. Even TS-first runtimes like Deno are (1) not TS but its own thing and most importantly (2) just JS engines with a frontend layer that treats TS as a first-class citizen (in Deno&#x27;s case, V8).It&#x27;s hard to tell if there will even be a runtime that somehow uses TS types to optimize even further (e.g. by proving that a function diverges) but to my knowledge they currently don&#x27;t and I don&#x27;t think there&#x27;s any in the works (or if that&#x27;s even possible while maintaining runtime soundness, considering you can &quot;lie&quot; to TS by casting to `unknown` and then back to any other type).

Ah thanks! I didn&#x27;t realize there was a Doom running on the TS type system. I stand corrected

I can think of a DOOM that WILL run faster…<a href="https:&#x2F;&#x2F;youtu.be&#x2F;0mCsluv5FXA" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;0mCsluv5FXA</a>

It is for me. If someone says TypeScript is faster than X, they rarely mean the build time. I understand other people&#x27;s points about TypeScript not being a runtime at all and only being a compiler, but when casually saying &quot;TypeScript is faster than say ruby&quot;, people do not mean the compiler.

Unfortunately many people only look at headlines, so titles do matter. People take them at face value.

It could have been a new TSC that compiles to WASM.

misleading titles are a no-no on HN.I agree with pseudopersonal in that the title should be changed. technically it&#x27;s not misleading, but not everyone uses or is familiar with typescript.

look, not to argue with a stranger on hacker news, lol, but genuine calm question here: is this really a helpful nit?  I know what you&#x27;re getting at but the blogpost itself doesn&#x27;t imply that JavaScript is 10x faster.  I could complain, about your suggested change, that it&#x27;s really `build and typecheck` time.  It&#x27;s a title.  Sometimes they don&#x27;t have _all_ the context.  That&#x27;s ok.

When I read the title I thought maybe they implemented a typescript to binary (instead of javascript) code compiler that speeds up the program by 10x, it would also have the added benefit of speeding up the compiler by 10x!I don&#x27;t think that is too far fetched either since typescript already has most of the type information.

I don&#x27;t think this is misleading for anyone familiar with Typescript. Typescript itself has no impact on performance, and it is known that the compilation and type-checking speed is often a problem. So I immediately assumed that it was about exactly that.

&gt; TypeScript does not &quot;run&quot;Except in the case of Doom, which can run on anything.

That could be a little confusing but (generally today) TypeScript does not &quot;run&quot;, JavaScript does.

You could make the same argument of anything but bytecode and even then some would debate if it&#x27;s really running directly enough on modern CPUs. In the end it still remains that you have the time it takes to build your project in a given language and the runtime performance of the end result. Those remain very useful distinctions regardless of how many layers of indirection occur between source code and execution.

Sure you can run Typescript. It&#x27;s a programming language, someone could always write an interpreter for it.

You can&#x27;t run Java either as it&#x27;s compiled to bytecode, yet when someone says &quot;we made Java 10x faster&quot; you wouldn&#x27;t assume that just the compilation got faster, right? When people market Rust projects as blazingly fast nobody assumes it&#x27;s about compilation, in part because a blazingly fast Rust compiler would be a miracle. Outside of this comment section people have always been using a programming language name for this because everyone knows what they mean.It would be possible that MS wrote a TypeScript compiler that emits native binaries and that made the language 10x faster, why not?

I don&#x27;t think it&#x27;s misleading at all, because you can&#x27;t run Typescript. Typescript is either compiled, transpiled or stripped down into another language and that&#x27;s what gets run in the end.

The explanations are of course correct, but I think you&#x27;re right and there&#x27;s not much downside to being clearer in the title. Maybe they decided against saying &quot;compiler&quot; because the performance boost also covers the language server.

Since you don&#x27;t execute TypeScript, and TS never has anything to do with the end resulting app, I don&#x27;t think it was misleading at all.

For anyone who uses TypeScript on a daily basis it&#x27;s not ambiguous at all. Everyone who works with TS knows the runtime code is JavaScript code that is generated by the TypeScript compiler. And it&#x27;s also pretty common knowledge that JavaScript is quite fast, but TS itself is not.

That&#x27;s debatable. I think most people that work with TS see it as a syntax extension for JS. Do you think JSX is a programming language?

Agree. TypeScript is primarily a programming language. Did they make the language faster? No. Hence, the title is misleading.

It was ambiguous to me. When someone says making a language X-times faster, it&#x27;s natural to think about runtime performance, not compile times. I know TS runs on JS runtimes, but I assumed, based on the title, they created&#x2F;modified a JS runtime to natively run TS fast.

This seems pedantic. As a TypeScript user who is aware of the conversations about build performance, the title is not ambiguous at all. I know exactly they are talking about build time.

Also it’s 4 times faster but runs multithreaded, which was tricky to do in JavaScript (but easier now).

The post title is a bit misleading. It should say a 10x faster build time, or a 10x faster TypeScript compiler. tsc (compiler) is 10x faster, but not the final TS program runtime. Still an amazing feat! But doom will not run faster&quot;To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by 10x, and substantially reduce memory usage.&quot;

Main overhead is shipping Go&#x27;s WASM runtime to the client

One question that springs to mind is the in-browser &quot;playground&quot; and hosted coding use-case. I assume WASM will be used in that scenario. I&#x27;m wondering what the overhead is there.

This was also surprising to me – C# is a really awesome and modern language.I happened to be doing a lot of C# and .NET dev when all this transition was happening, and it was very cool to be able to run .NET in Linux. C# is a powerful language with great and constantly evolving ideas in it.But then all the stuff between the runtimes, API surfaces, Core vs Framework, etc all got extremely confusing and off-putting. It was necessary to bring all these ecosystems together, but I wonder if that kept people away for a bit? Not sure.

All Azure contributions to CNCF are using a mix of Go and Rust, mostly.Here is a kind of weird, given the team.

Also, this is surprising because this was presented and led by Anders Hejlsberg, who is the creator of both C# and Typescript.If anyone should have picked C# it would be him.

I think the main thing is that they are porting, not re-writing. Current tsc is functional by nature and that&#x27;s makes go better fit.

&gt; Pity that they didn&#x27;t go with AOT compiled .NET, though.Yeah. It seems to be unfashionable somewhat even within Microsoft.(edit: it seems to be you and me and barely anyone else on HN advocating for C#)

Personally, Rust only makes sense in scenarios that automatic memory management of any kind is either unwanted, or it is a quixotic battle making the target group think otherwise.OS kernels, firmware, GPGPU,....If it is the ML inspired type system, there are plenty of options among compiled managed languages, true Go isn&#x27;t really on that camp, but whatever.

Dealing with references you typically find in a compiler is not a problem for Rust. Arena allocation and indices are your friend.

I wonder if this project can easily be integrated into Deno (built mainly in Rust)?

He also mentioned doing a line-for-line port. Assuming you could somehow manage that, you&#x27;d probably end up with something slower than JS (not entirely a joke). I&#x27;m a rust fanboy, but have to concede that Go was the be t choice here.If it was a fresh compiler then the choice would be more difficult.

If I recall in an article from a while back, the idea was originally rust, but the current compiler design had lots of references shared references that would make the port to rust a lot of work.

C# needs an interpreter (.NET runtime) while Go compiles down to a binary. And the toolchain allows you to compile for other architectures fairly easily.So that could be a fundamental reason why.

Anders Hejlsberg explains here: <a href="https:&#x2F;&#x2F;youtu.be&#x2F;10qowKUW82U?t=1154" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;10qowKUW82U?t=1154</a>. TL;DW:- C# is bytecode-first, Go targets native code. While C# does have AOT capabilities nowadays this is not as mature as Go&#x27;s and not all platforms support it. Go also has somewhat better control over data layout. They wanted to get as low-level as possible while still having garbage collection.- This is meant to be something of a 1:1 port rather than a rewrite, and the old code uses plain functions and data structures without an OOP style. This suits Go well while a C# port would have required more restructuring.

It seems it&#x27;s because AOT is a bit of a second fiddle in the dotnet ecosystem and native is a top priority for their case. After hearing the reasoning ( <a href="https:&#x2F;&#x2F;youtu.be&#x2F;ZlGza4oIleY?si=1GKSX61AF20VQr-G&amp;t=1000" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;ZlGza4oIleY?si=1GKSX61AF20VQr-G&amp;t=1000</a> ) I don&#x27;t blame them for choosing Go.

C# has become a poor jack of all trades, trying to be Java, Go and F# at the same time and actually being a shity poor version of all of them. On top of that .NET has become a very enterprisey bloatware. In all honesty, I&#x27;m not surprised that they went with Go, as it has a clear identity, a clear use-case which it caters for extremely well and doesn&#x27;t lose focus with trying to be too many other unrelated things at the same time.Maybe it&#x27;s time to stop eating everything that Microsoft sales folks&#x2F;evangelists spoon feed you and wake up to the fact that only because people paid by Microsoft to roll the drum about Microsoft products telling you that .NET and C# is oh so good and the best in everything, maybe it&#x27;s not actually that credible?Look at the hard facts. Every single product which Microsoft has built that actually matters (e.g. all their Azure CNCF stuff, Dapr, now this) is using non Microsoft languages and technologies.You won&#x27;t see Blazor being used by Microsoft or the 73rd reinvention of ASP.NET Core MVC Minimal APIs Razor Pages Hocus Pocus WCF XAML Enterprise (TM) for anything mission critical.

It&#x27;s not just a pity, it&#x27;s very surprising. In my eyes Go is a direct competitor of C#. Whenever you pick Go for a project, C# should have been a serious consideration. Hejlsberg designed C# and that a team that he&#x27;s an authority figure in would opt to use Go, a language which frankly I would not consider to build a compiler in is astounding.Not saying that in a judgemental way, I&#x27;m just genuinely surprised. What does this say about what Hejlsberg thinks of C# at the moment? I would assume one reason they don&#x27;t pick C# is because it&#x27;s deeply unpopular in the open source world. If Microsoft was so successful in making Typescript popular for open source work, why can&#x27;t they do it for C#?I have not opted to use C# for anything significant in the past decade or so. I am not 100% sure why, but there&#x27;s always been something I&#x27;d rather use. Whether that&#x27;s Go, Rust, Ruby or Haskell. I always enjoyed working in C#, I think it&#x27;s a well designed and powerful language even if it never made the top of my list recently. I never considered that there might be something so fundamentally wrong with it that not even Hejlsberg himself would use it to build a Typescript compiler.What&#x27;s wrong with C#?

I was asking myself the same questions.ah, answers below: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43333296">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43333296</a>

That makes sense if your project has similar constraints and requirements.I like when Microsoft doesn&#x27;t pretend that their technologies are the right answer for every problem.

They cited code style and porting as reasons to use go over c#, not performance.

One unrelated team at Microsoft doesn&#x27;t &#x27;believe&#x27; in .NET is enough to make you change direction?

&gt;Pity that they didn&#x27;t go with AOT compiled .NET, though.I was trying ot push .net as our possible language for somehow high performance executables. Seeing this means I&#x27;ll stop trying to advocate for it. If even this team doesn&#x27;t believe in it.

There are some external projects that have tried to port tsc to native. stc[0], for instance, was one. Iirc it started out in Go since it had a more comparable type system (they both use duck typing) making it easier to do one-to-one conversions of code from one language to the other. I’m not totally sure why it ended up pivoting to rust.[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;dudykr&#x2F;stc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;dudykr&#x2F;stc</a>

Hejlsberg discusses the decision not to use C# here: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=10qowKUW82U&amp;t=1154s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=10qowKUW82U&amp;t=1154s</a>

&gt; I love that they picked Go instead of the fashion to go RustThis seems super petty to me. Like, if at the end of the day you get a binary that works on your OS and doesn’t require a runtime, why should you “love” that they picked one language over another? It’s exactly the same outcome for you as a user.I mean, if you wanted to contribute to the project and you knew go better than rust, that would make sense. But sounds like you just don’t like rust because of… reasons, and you’re just glad to see rust “fail” for their use case.

&gt; that seems to be the norm now.According to whom?

Even though I have my considerations regarding Go, I love that they picked Go instead of the fashion to go Rust that seems to be the norm now.A compiled managed language is much better approach for userspace applications.Pity that they didn&#x27;t go with AOT compiled .NET, though.

TL:DR;- Native executable support on all major platforms- He doesn&#x27;t seen to believe that AOT compiled C# can give the best possible performance on all major platforms- Good control of the layout of data structures- Had to have garbage collection- Great concurrency support- Simple, easy to approach, and great tooling

There’s also an FAQ discussion about the language choice: <a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411</a>

Anders explain why Go in this podcast:<a href="https:&#x2F;&#x2F;youtu.be&#x2F;ZlGza4oIleY?t=1005" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;ZlGza4oIleY?t=1005</a>

A Microsoft project led by the chief architect of C#, no less.

same reason i hate gradle&#x2F;maven&#x2F;ant: shipping a big runtime that many devs won&#x27;t have installed for a build tool is bad. even with AOT, you still need a dotnet runtime.

I wonder, for a Microsoft project, why not C#? Would have been a nice win for the home team.

tl;dr: TypeScript compiler (!) was implemented in TypeScript, new one is in Gohalf of the perf gain is from moving to native code, other half is from concurrency

TypeScript compiler is more of a transpiler, not a typical compiler that creates a binary. I don&#x27;t think it was weird choice.

Yep. I remember years ago when they celebrating getting the C# compiler working in C#.

“Nice” doesn’t mean “well suitable for writing a compiler in”. It’s strange to think that all languages should be equally good for writing all kinds of things, and choosing a web language for a non-web task is doubly strange.

Bootstraping compilers is a common activity and TypeScript is a nice language.

I don&#x27;t consider it strange, and I&#x27;m not alone: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37171801">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=37171801</a>

note that as others have said, &quot;compiled&quot; is a stretch, but nevertheless...

It is fairly common, yes. Sometimes those compilers (or interpreters) aren&#x27;t the primary implementation, but it&#x27;s certainly a thing that happens often.Most of the Rust compiler is in Rust, that&#x27;s correct, but it does by default use LLVM to do code generation, which is in C++.

is it not common to write compilers for languages in the language being compiled itself? rust does this i think?

Yet people wouldn’t write a Fortran compiler in Fortran, or a MATLAB compiler in MATLAB.

Its not strange, its very common. Its called &quot;bootstrapping&quot;.&gt; Bootstrapping is a fairly common practice when creating a programming language. Many compilers for many programming languages are bootstrapped, including compilers for ALGOL, BASIC, C, C#, Common Lisp, D, Eiffel, Elixir, Go, Haskell, Java, Modula-2, Nim, Oberon, OCaml, Pascal, PL&#x2F;I, Python, Rust, Scala, Scheme, TypeScript, Vala, Zig and more.<a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bootstrapping_(compilers)" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Bootstrapping_(compilers)</a>

It’s not obvious from the text, but the compiler was previously written in TypeScript (which was kind of a strange choice for the language to write a compiler in).

a couple of commits merged yrs back, things I stumbled on that I used as an excuse to learn more about internals

did you contribute to the current TypeScript codebase? (not intended snarky, just curious)

Too bad they didn’t choose Rust, would have loved contributing (not picking up Go, sry)

We had Daniel and Anders on the podcast to talk about the how and why of the native port if anyone is looking for an in-depth discussion → <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZlGza4oIleY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZlGza4oIleY</a>

I am actually shocked that Anders chose Go over C# for this port.

There is this with does not do type checking:<a href="https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;typescript&#x2F;announcing-typescript-5-8&#x2F;#the---erasablesyntaxonly-option" rel="nofollow">https:&#x2F;&#x2F;devblogs.microsoft.com&#x2F;typescript&#x2F;announcing-typescr...</a>This will only allow you to run your TypeScript in Node, but does not perform type checking, and I don&#x27;t believe has any plans to. This is from Node.js 23.9.0<a href="https:&#x2F;&#x2F;nodejs.org&#x2F;api&#x2F;typescript.html#type-stripping" rel="nofollow">https:&#x2F;&#x2F;nodejs.org&#x2F;api&#x2F;typescript.html#type-stripping</a>I don&#x27;t believe Node has any plans for type checking TS.

Has there been any talks&#x2F;progress on native inclusion of typescript for type checking, for path resolution with node.js without using tsc, ts-node, tsx, native vscode TS debugging and testing support? We are 22 versions down on node.js and still the support seems to be limited at best. Is it possible to maybe share a roadmap of what is being done in this territory

haha yep, everyone thought it was related to Vite. which I guess I kinda is?

Ah that&#x27;ll be the thing Wes was under NDA about and teasing how excited he was on twitter last week!

Syntax podcast has a conversation with Anders and Dan about it here: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZlGza4oIleY&amp;t=1s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=ZlGza4oIleY&amp;t=1s</a>

&gt; I&#x27;m surprised to hear that idiomatic Golang resembles the existing coding patterns of the tsc codebase. I&#x27;ve never felt that idiomatic code in Golang resembled idiomatic code in TypeScript.To be fair, they didn&#x27;t actually say that. What they said was that idiomatic Go resembles their existing patterns. I&#x27;d imagine what they mean by that is that a port from their existing patterns to Go is much closer to a mechanical 1:1 process than a port to Rust or C#. Rust is the obvious choice for a fully greenfield implementation, but reorganizing around idiomatic Rust patterns would be much harder for most programs that are not already written in a compatible style. e.g. For Rust programs, the precise ownership and transfer of memory needs to be modelled, whereas Go and JS are both GC&#x27;d and don&#x27;t require this.For a codebase that relies heavily on exception handling, I can imagine a 1:1 port would require more thought, but compilers generally need to have pretty good error recovery so I wouldn&#x27;t be surprised if tsc has bespoke error handling patterns that defers error handling and passes around errors as values a lot; that would map pretty well to Go.Most TypeScript projects are very far away from compiler code, so that this wouldn&#x27;t resemble typical TypeScript isn&#x27;t too surprising. Compilers written in Go also don&#x27;t tend to resemble typical Go either, in fairness.

to be fair, there&#x27;s not many ways to implement a token matcher.though looking at that flood of loose ifs+returns, i kinda wish they used rust :)

In the embedded video they show some of the code side by side and it is just a ton of if statements.<a href="https:&#x2F;&#x2F;youtu.be&#x2F;pNlq-EVld70?si=UaFDVwhwyQZqkZrW&amp;t=323" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;pNlq-EVld70?si=UaFDVwhwyQZqkZrW&amp;t=323</a>

I&#x27;m not involved in this rewrite, but I made some minor contributions a few years ago.TSC doesn&#x27;t use many union types, it&#x27;s mostly OOP-ish down-casting or chains of if-statements.One reason for this is I think performance; most objects are tagged by bitsets in order to pack more info about the object without needing additional allocations. But TypeScript can&#x27;t really (ergonomically) represent this in the type system, so that means you don&#x27;t get any real useful unions.A lot of the objects are also secretly mutable (for caching&#x2F;performance) which can make precise union types not very useful, since they can be easily invalidated by those mutations.

&gt; By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast, languages that require fundamental rethinking of memory management, mutation, data structuring, polymorphism, laziness, etc., might be a better fit for a ground-up rewrite, but we&#x27;re undertaking this more as a port that maintains the existing behavior and critical optimizations we&#x27;ve built into the language. Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.--<a href="https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;microsoft&#x2F;typescript-go&#x2F;discussions&#x2F;411</a>I haven&#x27;t looked at the tsc codebase. I do currently use Golang at my job and have used TypeScript at a previous job several years ago.I&#x27;m surprised to hear that idiomatic Golang resembles the existing coding patterns of the tsc codebase. I&#x27;ve never felt that idiomatic code in Golang resembled idiomatic code in TypeScript. Notably, sum types are commonly called out as something especially useful in writing compilers, and when I&#x27;ve wanted them in Golang I&#x27;ve struggled to replace them.Is there something special about the existing tsc codebase, or does the statement about idiomatic Golang resembling the existing codebase something you could say about most TypeScript codebases?

They&#x27;re not getting &quot;faster typescript&quot;, they&#x27;re getting &quot;a faster typescript transpiler &#x2F; type checker&quot;; subtle but important difference. The runtime of TS is Javascript engines, and most of &quot;typescript transpilation&quot; is pretty straightforward removal of type information.Anyway, JS is not immature in performance per se, but in this particular use case, a native language is faster. But they had to solve the problem first before they could decide what language was best for it.

So in order to get &quot;Faster TypeScript&quot; you have to port the existing &quot;transpiler&quot; in a complied language that delivers said faster performance.This is an admission that these JavaScript based languages (including TypeScript) are just completely unsuitable for these performance and scalable situations, especially when the codebase scales.As long as it is a compiled language with reasonable performance and with proper memory management situations, Go is the unsurprising choice, but the wise choice to solve this problem.But this choice definitively shows (and as admitted by the TS team) how immature both JavaScript and TypeScript are in performance and scalability scenarios and should be absolutely avoided for building systems that need it. Especially in the backend.Just keep it in the frontend.

Yes, 100% agree. We&#x27;ve spent so much time chasing down what makes our build slow. Obviously that is less important now, but hopefully they&#x27;ve laid the foundation for when our code base grows another 10x.

I know this is a port but I really hope the team builds in performance debugging tools from the outset. Being able to understand _why_ a build or typecheck is taking so long is sorely missing from today&#x27;s Typescript.

A 10x Faster TypeScript