by DanRosenwasser on 3/11/25, 2:32 PM with 908 comments
by DanRosenwasser on 3/11/25, 2:39 PM
by bcherny on 3/11/25, 2:45 PM
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.
by zoogeny on 3/11/25, 4:25 PM
Yet projects inevitably get to the stage where a more native representation wins out. I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language.
It makes me think I should be starting any project I have in the lowest level representation that allows me some ergonomics. Maybe more reason to lean into Zig? I don't mean for places where something like Rust would be appropriate. I mean for anything I would consider using a "good enough" scripting language.
It honestly has me questioning my default assumption to use JS runtimes on the server (e.g. Node, deno, bun). I mean, the benefit of using the same code on the server/client has rarely if ever been a significant contributor to project maintainability for me. And it isn't that hard these days to spin up a web server with simple routing, database connectivity, etc. in pretty much any language including Zig or Go. And with LLMs and language servers, there is decreasing utility in familiarity with a language to be productive.
It feels like the advantages of scripting languages are being eroded away. If I am planning a career "vibe coding" or prompt engineering my way into the future, I wonder how reasonable it would be to assume I'll be doing it to generate lower level code rather than scripts.
by kevlened on 3/11/25, 5:41 PM
1. https://github.com/dudykr/stc - Abandoned (https://github.com/swc-project/swc/issues/571#issuecomment-1...)
2. https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.
by pjmlp on 3/11/25, 2:51 PM
A compiled managed language is much better approach for userspace applications.
Pity that they didn't go with AOT compiled .NET, though.
by wesbos on 3/11/25, 2:56 PM
by grantwu on 3/11/25, 3:01 PM
--https://github.com/microsoft/typescript-go/discussions/411
I haven'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'm surprised to hear that idiomatic Golang resembles the existing coding patterns of the tsc codebase. I'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've wanted them in Golang I'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?
by dimgl on 3/11/25, 3:42 PM
Why _not_ use Go?
by 0xcb0 on 3/11/25, 3:30 PM
Never been a big fan of MS, but must say that typescript is well done imho. thanks for it and all the hard work!
by dustedcodes on 3/11/25, 5:40 PM
by zestyping on 3/12/25, 12:40 AM
I would argue it needs editing, as it violates the HN guideline:
> use the original title, unless it is misleading or linkbait; don't editorialize.
by haxiomic on 3/11/25, 5:58 PM
Opened discussion [1]
- [0] https://github.com/microsoft/typescript-go/discussions/410
- [1] https://github.com/microsoft/typescript-go/discussions/467
by adriancooney on 3/11/25, 3:10 PM
by aib on 3/12/25, 6:56 AM
../../../tmp/typescript-go/built/local/lib.dom.d.ts:27982:6 - error TS2300: Duplicate identifier 'KeyType'.
27982 type KeyType = "private" | "public" | "secret";
~~~~~~~
../../../tmp/typescript-go/built/local/lib.webworker.d.ts:9370:6 - 'KeyType' was also declared here.
9370 type KeyType = "private" | "public" | "secret";
~~~~~~~
Running it in another portion results in SIGSEGV with a bad/nil pointer defererence, which puts me in the camp of people questioning the choice of Go.
by slackerIII on 3/11/25, 3:11 PM
by electroly on 3/11/25, 2:52 PM
by DeathArrow on 3/12/25, 6:23 AM
Strange choice to use Go for the compiler instead of C# or F#.
Now if they will have problems, they will depend on the Go team at Google to fix them.
by stuaxo on 3/11/25, 6:14 PM
by robinsonrc on 3/11/25, 7:25 PM
by ethan_smith on 3/11/25, 3:35 PM
Hopefully this would also reduce the memory footprint because my VS Code intelisense keeps crashing unless I give it like 70% of my RAM, its probably because of our fairly large graphql.ts file which contains auto-generated grapqhl types.
by tracker1 on 3/11/25, 7:23 PM
This isn't a knock against Go or necessarily a promotion of Rust, just seems like a lot of duplicated effort. I don't know the timelines in place or where the community projects were vs. the internal MS project.
by hamandcheese on 3/11/25, 8:17 PM
I kinda wonder, though, if in 5 or 10 years how many of these tools will still be crazy fast. Hopefully all of them! But I also would not be surprised if this new performance headroom is eaten away over time until things become only just bearable again (which is how I would describe the current performance of typescript).
by eapriv on 3/11/25, 2:53 PM
by cjbgkagh on 3/11/25, 4:44 PM
by joewood1972 on 3/11/25, 2:50 PM
by goda90 on 3/11/25, 11:54 PM
by steve_adams_86 on 3/11/25, 2:56 PM
by maginx on 3/13/25, 7:43 PM
by CLiED on 3/11/25, 9:25 PM
by whoknowsidont on 3/12/25, 6:32 PM
Programming languages are tools. Nothing more.
by synergy20 on 3/11/25, 9:21 PM
by zombot on 3/12/25, 2:00 PM
by presentation on 3/11/25, 2:46 PM
by DanielHB on 3/11/25, 4:17 PM
by odyssey7 on 3/11/25, 6:59 PM
> immutable data structures --> "we are fully concurrent, because these are what I often call embarrassingly parallelizable problems"
The relationship of their performance gains to functional programming ideas is explained beginning at 8:14 https://youtu.be/pNlq-EVld70?feature=shared&t=522
by trashface on 3/11/25, 5:27 PM
Also I get the sense from the video that it still outputs only JS. It would be nice if we could build typescript executables that didn't require that, even if was just WASM, though that is more of a different backend rather than a different compiler.
Edit: C# was addressed: https://github.com/microsoft/typescript-go/discussions/411#d...
by register on 3/11/25, 4:24 PM
by gwbas1c on 3/11/25, 5:10 PM
> The JS-based codebase will continue development into the 6.x series, and TypeScript 6.0 will introduce some deprecations and breaking changes to align with the upcoming native codebase.
> While some projects may be able to switch to TypeScript 7 upon release, others may depend on certain API features, legacy configurations, or other constraints that necessitate using TypeScript 6. Recognizing TypeScript’s critical role in the JS development ecosystem, we’ll still be maintaining the JS codebase in the 6.x line until TypeScript 7+ reaches sufficient maturity and adoption.
It sounds like the Python 2 -> 3 migration, or the .Net Framework 4 -> .Net 5 (.Net Core) migration.
I'm still in a multi-year project to upgrade past .Net Framework 4; so I can certainly empathize with anyone who gets stuck on TS 6 for an extended period of time.
by paxys on 3/11/25, 8:11 PM
by melodyogonna on 3/11/25, 4:46 PM
My theory - that Go will always be the choice for things like this when ease, simplicity, and good (but not absolute) performance is the goal - continues to hold.
by alberth on 3/11/25, 4:31 PM
And if it's run-time, can we expect browsers to replace V8 with this Go library?
(I realize this is a noob/naive question - apologies)
by umvi on 3/11/25, 6:02 PM
by stef-13013 on 3/12/25, 10:47 AM
So, to me, Hejlsberg's choice sounds pretty logical.
After, why go ? why not...
by skwee357 on 3/11/25, 9:38 PM
Also, what’s up with 10x everywhere? Why not 9.5x or 11x?
by vivzkestrel on 3/11/25, 2:56 PM
by nailer on 3/11/25, 5:37 PM
by aiiizzz on 3/11/25, 5:58 PM
by localghost3000 on 3/11/25, 4:04 PM
by NiloCK on 3/12/25, 12:13 PM
See how many spaghetti types get churned through this faster transpiler.
Didn't expect Jevons paradox popping up for compilers.
by jujadjwdfs on 3/12/25, 2:54 AM
If the Typescript team were to go with Rust or C# they would have to contend with async/await decoration and worry about starvation and monopolization.
Go frees the developer from worrying about these concerns.
by sublinear on 3/12/25, 5:49 AM
by tomatofrank on 3/11/25, 7:22 PM
I've been revisiting my editing setup over the last 6 months and to my surprise I've time traveled back to 2012 and am once again really enjoying Sublime Text. It's still by far the most performant editor out there, on account of the custom UI toolkit and all the incredibly fast indexing/search/editing engines (everything's native).
Not sure how this announcement impacts VSCode's UI being powered by Electron, but having the indexing/search/editing engines implemented in Go should drastically improve my experience. The editor will never be as fast as Sublime but if they can make it fast enough to where I don't notice the indexing/search/editing lag in large projects/files, I'd probably switch back.
by wodenokoto on 3/12/25, 6:18 AM
by srott on 3/11/25, 10:47 PM
by dimitropoulos on 3/11/25, 2:38 PM
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/concurrency support. Go supports both shared memory (with explicit synchronization) and message-passing concurrency (via goroutines & 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!
by massive-fail on 3/11/25, 7:17 PM
by dev1ycan on 3/11/25, 4:04 PM
by darthrupert on 3/11/25, 5:56 PM
by jbverschoor on 3/11/25, 2:58 PM
by subarctic on 3/11/25, 5:23 PM
by g0ld3nrati0 on 3/11/25, 7:59 PM
by accassar on 3/11/25, 11:53 PM
by garbagepatch on 3/11/25, 4:49 PM
by kopirgan on 3/11/25, 3:37 PM
by neycoda on 3/11/25, 11:19 PM
by aklein on 3/11/25, 6:50 PM
by dlahoda on 3/12/25, 11:50 AM
as i see next planned feature is macro in TS(joke, just because 3rd book is macro).
by Ericson2314 on 3/12/25, 3:47 AM
by Traubenfuchs on 3/11/25, 7:39 PM
by sesm on 3/11/25, 4:44 PM
by deskr on 3/11/25, 6:16 PM
I'll give Typescript yet another go. I really like it and wish I could use it. It's just that any project I start, inevitably the sourcemap chain will go wrong and I lose the ability to run the debugger in any meaningful way.
by pizlonator on 3/11/25, 3:32 PM
by thund on 3/11/25, 2:55 PM
by gqgs on 3/12/25, 5:25 AM
by lxe on 3/11/25, 5:55 PM
by reverseblade2 on 3/11/25, 4:09 PM
by falleng0d on 3/11/25, 7:00 PM
by DrBenCarson on 3/11/25, 4:49 PM
Do any other well-adopted tools in the ecosystem use Go?
by zerr on 3/11/25, 4:09 PM
by emcell on 3/11/25, 6:46 PM
by algorithmsRcool on 3/11/25, 2:56 PM
by alexisread on 3/11/25, 8:56 PM
by _benton on 3/11/25, 4:58 PM
sigh
by singularity2001 on 3/11/25, 9:56 PM
by arrty88 on 3/11/25, 11:12 PM
by pseudopersonal on 3/11/25, 2:47 PM
"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."
by DrammBA on 3/11/25, 5:04 PM
by Starlord2048 on 3/11/25, 4:17 PM
by osigurdson on 3/11/25, 10:57 PM
Why not C#? https://youtu.be/10qowKUW82U?t=1155
by ragnese on 3/11/25, 3:16 PM
/s
by tosh on 3/11/25, 2:53 PM
half of the perf gain is from moving to native code, other half is from concurrency
by 29athrowaway on 3/11/25, 10:29 PM
10x faster compilation, not runtime performance
by lawls on 3/11/25, 7:23 PM
by Delomomonl on 3/11/25, 3:42 PM
Why is typescript not already a standard natively supported by browers?!
by atak1 on 3/11/25, 4:52 PM
by zidad on 3/11/25, 3:25 PM
by rvz on 3/11/25, 3:08 PM
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.