The discussion is characterized by a split between praise for .NET 11's technical features and severe criticism of Microsoft's aggressive upgrade cycle, alongside a contentious debate comparing C#'s complexity against Go's simplicity. Participants disagree on whether the ecosystem's maturity justifies the migration burden and argue over specific language design choices like ConfigureAwait and generics.
306 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4 · Supporting reply 5 · Supporting reply 6 · Supporting reply 7 · Supporting reply 8microsoft
typescript-go
Go2025–2026
microsoft / typescript-go · Archived
typescript-go
Staging repo for development of native port of TypeScript
49Distinct people
52Mentions
0Explicit recommenders
26.1KGitHub stars
What to know before exploring
What it is
Staging repo for development of native port of TypeScript
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.
Mentions over time
HN mentions by month52 dated mentions
Observed mentions: 2025-03-11 15:01:43 UTC to 2026-10-21 11:18:41 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Mar 2025 | 2025-03-01 00:00:00 UTC | 2025-04-01 00:00:00 UTC | 24 | 2 | 22 |
| Apr 2025 | 2025-04-01 00:00:00 UTC | 2025-05-01 00:00:00 UTC | 2 | 0 | 2 |
| May 2025 | 2025-05-01 00:00:00 UTC | 2025-06-01 00:00:00 UTC | 3 | 0 | 3 |
| Jun 2025 | 2025-06-01 00:00:00 UTC | 2025-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2025 | 2025-07-01 00:00:00 UTC | 2025-08-01 00:00:00 UTC | 1 | 0 | 1 |
| Aug 2025 | 2025-08-01 00:00:00 UTC | 2025-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2025 | 2025-09-01 00:00:00 UTC | 2025-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2025 | 2025-10-01 00:00:00 UTC | 2025-11-01 00:00:00 UTC | 1 | 0 | 1 |
| Nov 2025 | 2025-11-01 00:00:00 UTC | 2025-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2025 | 2025-12-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 5 | 0 | 5 |
| Jan 2026 | 2026-01-01 00:00:00 UTC | 2026-02-01 00:00:00 UTC | 3 | 1 | 2 |
| Feb 2026 | 2026-02-01 00:00:00 UTC | 2026-03-01 00:00:00 UTC | 1 | 0 | 1 |
| Mar 2026 | 2026-03-01 00:00:00 UTC | 2026-04-01 00:00:00 UTC | 3 | 0 | 3 |
| Apr 2026 | 2026-04-01 00:00:00 UTC | 2026-05-01 00:00:00 UTC | 1 | 0 | 1 |
| May 2026 | 2026-05-01 00:00:00 UTC | 2026-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2026 | 2026-06-01 00:00:00 UTC | 2026-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2026 | 2026-07-01 00:00:00 UTC | 2026-08-01 00:00:00 UTC | 6 | 0 | 6 |
| Aug 2026 | 2026-08-01 00:00:00 UTC | 2026-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2026 | 2026-09-01 00:00:00 UTC | 2026-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2026 | 2026-10-01 00:00:00 UTC | 2026-11-01 00:00:00 UTC | 2 | 0 | 2 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
This Repo Is Closed
This was the staging repo for the TypeScript 7.0 release during the native port process, which is now completed!
Please continue development and discussion in the original repo
This repo will be permanently archived in September 2026.
TypeScript 7
Not sure what this is? Read the announcement post!
Preview
A preview build is available on npm as @typescript/native-preview.
npm install @typescript/native-preview
npx tsgo # Use this as you would tsc.
For TypeScript 7.0 RC and later, the command name is tsc.
A preview VS Code extension is available on the VS Code marketplace.
To use this, set this in your VS Code settings:
{
"js/ts.experimental.useTsgo": true
}
What Works So Far?
This is still a work in progress and is not yet at full feature parity with TypeScript. Bugs may exist. Please check this list carefully before logging a new issue or assuming an intentional change.
Feature
Status
Notes
Program creation
done
Same files and module resolution as TS 6.0. Not all resolution modes supported yet.
Parsing/scanning
done
Exact same syntax errors as TS 6.0
Commandline and tsconfig.json parsing
done
Done, though tsconfig errors may not be as helpful.
Type resolution
done
Same types as TS 6.0.
Type checking
done
Same errors, locations, and messages as TS 6.0. Types printback in errors may display differently.
JavaScript-specific inference and JSDoc
done
Complete, but intentionally lacking some features. Declaration emit differs greatly, intentionally, to be closer to TS declarations.
JSX
done
-
Declaration emit
done
-
Emit (JS output)
done
-
Watch mode
done
-
Build mode / project references
done
-
Incremental build
done
-
Language service (LSP)
in progress
Nearly all features implemented.
API
not ready
-
Definitions:
done aka "believed done": We're not currently aware of any deficits or major work left to do. OK to log bugs
in progress: currently being worked on; some features may work and some might not. OK to log panics, but nothing else please
prototype: proof-of-concept only; do not log bugs
not ready: either haven't even started yet, or far enough from ready that you shouldn't bother messing with it yet
Other Notes
Long-term, we expect that this repo and its contents will be merged into microsoft/TypeScript.
As a result, the repo and issue tracker for typescript-go will eventually be closed, so treat discussions/issues accordingly.
For a list of intentional changes with respect to TypeScript 6.0, see CHANGES.md.
Contributing
This project welcomes contributions and suggestions. Most contributions require you to agree to a
Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us
the rights to use your contribution. For details, visit Contributor License Agreements.
When you submit a pull request, a CLA bot will automatically determine whether you need to provide
a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions
provided by the bot. You will only need to do this once across all repos using our CLA.
This project has adopted the Microsoft Open Source Code of Conduct.
For more information see the Code of Conduct FAQ or
contact opencode@microsoft.com with any additional questions or comments.
Trademarks
This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft
trademarks or logos is subject to and must follow
Microsoft's Trademark & Brand Guidelines.
Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship.
Any use of third-party trademarks or logos are subject to those third-party's policies.
Read the full README on GitHubWhat Hacker News says
52 sourcesThere are plenty of CoPilot contributions on tsgo repo, forgotten which company Typescript development is sponsored by?
https://github.com/microsoft/typescript-go/pull/4313
In Tsrs: A Port of TypeScript to RustI suppose my comment sort of implies this. I think the naive knee jerk reaction is that if you can spit out perfect machine level code against a specification, then logically being closer to bare metal would help with performance. However, without knowing the details of how things worked it is tough to say whether it is truly "reasonable" or not.
But more importantly, the Typescript team themselves [1] picked Golang mostly out of ergonomics and ease of porting at the time. It is becoming more increasingly more to "taste" what ergonomics means. Notably, they did not pick it because they believed it to be the fastest option. But speed was on the mind, giving way to ergonomics and ease of porting. At least, this is my read.
[1] https://github.com/microsoft/typescript-go/discussions/411
In Port of the TypeScript compiler, checker and lsp to Rust, by LLMIMHO it's not the same car, even if its engine initially was a 1:1 rebuild using other alloys. But you're right I overstated and made myself look dumb (by a lot really - this is nothing like having 2 independent C compilers for instance).
What's taken 1:1, deliberately, was the compiler core. That was almost perfectly 50% of the non-test code. A close translation of that was a starting point, but open CHANGES.md or it's history and you'll see it's quickly diverging even on its surface.
The closest matching, interesting large area of it is probably the checker. Easily recognizable on a function level, even if not being a single file anymore:
https://github.com/microsoft/typescript-go/tree/main/interna...
https://raw.githubusercontent.com/microsoft/TypeScript/refs/... (The TS file is 3MB and github won't display it inline)
You'll find a lot
Read the rest
of the same data structures (as far as that's possible in a TS-to-Go translation + ripples from areas that were more heavily changed) and functions lying around, just in slightly different places. Because of the AST changes and TS/Go differences on a line-level each function might look different, but where there is a loop in the TS one, there's probably one in Go.
The other half of the project is heavily changed or completely new/different (like concurrency, less weird language service).
It's funny, but a large reason for why Go was chosen was explicitly because it has semantics close to TypeScript and that made it automatable:
https://github.com/microsoft/typescript-go/discussions/411#d...
> But this wasn't a compiler redesign, and the TypeScript to Go move was far more automatable and more one-to-one in its mapping.
So basically the opposite of what you're saying.
In How is the Bun rewrite in Rust going?https://devblogs.microsoft.com/typescript/typescript-native-...
https://github.com/microsoft/typescript-go
In After 7 years in production, Scarf has reluctantly moved away from HaskellThere's the blog post (by Anders Hejlsberg, the author of Turbo Pascal, chief architect of Delphi, currently lead architect of C# and a core developer of TS; I'd say he knows his languages), but they also posted FAQs, here's some good reads:
The blog post: https://devblogs.microsoft.com/typescript/typescript-native-...
Why Go? https://github.com/microsoft/typescript-go/discussions/411
Why a port instead of a rewrite? https://github.com/microsoft/typescript-go/discussions/410
In TypeScript 7> this TS migration started long before AI was able to help
Yes, but that doesn't mean it wasn't also "helped" along by AI.
See:
1. https://github.com/microsoft/typescript-go/pull/1387
2. https://github.com/microsoft/typescript-go/pull/2978
3. https://github.com/microsoft/typescript-go/pull/1138
4. etc...
Copilot is the "user" with the 2nd most commits (and the 15th and 19th too), and that's just what's been tracked in git.
---
The initial port was automated, then devs got in there, then LLMs got in there.
In TypeScript 7The entire article is speculation. The real answer was posted by Ryan Cavanaugh in the official repo over a year a go: https://github.com/microsoft/typescript-go/discussions/411 Why would trust anything else?
In Why TypeScript 7.0 Was Rewritten in GoA quote from the official FAQ - https://github.com/microsoft/typescript-go/discussions/411:
>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're undertaking this more as a port that maintains the existing behavior and critical optimizations we've built into the language. Idiomatic Go strongly resem
Read the rest
bles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.
TLDR: Typescript -> Go is much easier than Typescript -> Rust/Zig/$OTHERNATIVELANG
Can't wait for tsgo to be generally available and supported. It's what, at least a quarter or maybe 2 quarters away?
Also here's a discussion I always like reading: Why Go? https://github.com/microsoft/typescript-go/discussions/411
In TypeScript 6.0The typescript language server (along with the rest of the compiler) is being rewritten in go for Typescript 7. This work has been going on in parallel with the work on 6.0. The go port has most features of 6.0 already and you can follow its progress and read more about it here:
https://github.com/microsoft/typescript-go
In TypeScript 6.0 RCMy deepest thanks to one @AlCalzone for stepping up to Opus port Decorators to tsgo.
https://github.com/microsoft/typescript-go/pull/2926
It would have been an affront to have a 6.0 that shipped without the means to work for so so many javascript frameworks/libraries. AlCalzone utterly saving the day.
I also am so so so thankful that maybe perhaps after what felt like a never ending dolldrums, we may finally be getting decorator support in some browsers. What a colossal relief it will be to see the progress of the language become manifest.
In TypeScript 6.0 RCCan't wait for the first crypto-attack on a front-end JS library that's caused by a Go package vuln. God knows how `pnpm audit` will handle Go-module dependencies.
(I opened an issue against typescript-go to flag this https://github.com/microsoft/typescript-go/issues/2825 )
In Fastest Front End Tooling for Humans and AIAssemblyScript was just mentioned as some prior work, I don't think that AssemblyScript would work as is for games.
I realize the major issues with TS->C++ though (or any language to C++, Facebook has prior work converting php to C++ https://en.wikipedia.org/wiki/HipHop_for_PHP that was eventually deprecated in favor of HHVM). I think that iteratively improving the JS engine (Mystral.js the one that is not open source yet but is why MystralNative exists) to work with the compiler would be the first step and ensuring that games and examples built on top with a subset of TS is a starting point here. I don't think that the goal for MystralScript should be to support Three.js or any other engine to begin with as that would end up going down the same compatibility pits that hiphop did.
Being able to update the entire stack here is actually ver
Read the rest
y useful - in theory parts of mystral.js could just be embedded into mystralnative (separate build flags, probably not a standard build) avoiding any TS->C++ compilation for core engine work & then ensuring that games built on top are using the strict subset of TS that does work well with the AOT compilation system. One option for numbers is actually using comment annotations (similar to how JSDoc types work for typescript compiler, specifically using annotations in comments to make sure that the web builds don't change).
Re: TS compiler - I do have some basics started here and I am already seeing that tests are pretty slow. I don't think that the tsgo compiler has a similar API though for parsing & emitters right now, so as much as I would like to switch to it (I have for my web projects & the speed is awesome), I don't think I can yet until the API work is clarified: https://github.com/microsoft/typescript-go/discussions/455
Showing the 15 most recent of 52 sources. Enable JavaScript to search and browse every indexed mention.