Jerod Santo (Mar 12 2025 at 20:33): Jerod Santo (Mar 12 2025 at 20:33):Curious what everyone's thoughts/excitement level are on yesterday's announcement from Anders Hejlsberg and the TypeScript team.
Adam and I recorded a little something about it: https://youtu.be/73cUBCzS8NQ
Tim Uckun (Mar 12 2025 at 20:53):I read the news but I thought it was the compilation speed that was sped up not the runtime.
Alex Barnes (Mar 12 2025 at 21:00):Yes I thought the same, the press release spoke of 10x speed increases in compilation. Don't remember seeing anything about runtime.
Ron Waldon-Howe (Mar 12 2025 at 21:13):Well, the runtime is up to JavaScriptCore, V8, Spider monkey, etc
It's plain JavaScript at runtime
Ron Waldon-Howe (Mar 12 2025 at 21:16):But yeah, very interesting
And the presentation mentioned "porting" and "circular references" which does explain why they wouldn't go for Rust, as a TypeScript code base is going to have loads of data structures and data flows that need a bit of a rethink in Rust
What's strange is that both Go and C# seem like reasonable targets for porting TypeScript line by line, but they chose not to go with C#
Alex Barnes (Mar 12 2025 at 21:20):From the interview:
Dimitri: Was C# considered?
Anders: It was, but I will say that I think Go definitely is -- it's, I'd say, the lowest-level language we can get to and still have automatic garbage collection. It's the most native-first language we can get to and still have automatic GC. In C#, it's sort of bytecode first, if you will; there is some ahead-of-time compilation available, but it's not on all platforms and it doesn't have a decade or more of hardening. It was not geared that way to begin with. Additionally, I think Go has a little more expressiveness when it comes to data structure layout, inline structs, and so forth. For us, one additional thing is that our JavaScript codebase is written in a highly functional style -- we use very few classes; in fact, the core compiler doesn't use classes at all -- and that is actually a characteristic of Go as well. Go is based on functions and data structures, whereas C# is heavily OOP-oriented, and we would have had to switch to an OOP paradigm to move to C#. That transition would have involved more friction than switching to Go. Ultimately, that was the path of least resistance for us.
Ron Waldon-Howe (Mar 12 2025 at 21:32):Ah, that makes sense
Ron Waldon-Howe (Mar 12 2025 at 21:32):I forgot that C# (like Java that inspired it) is classes first
Ron Waldon-Howe (Mar 12 2025 at 21:35):I really wish more folks would follow Mitchell Hashimoto's example and feel free to say that they make technical choices based on subjective factors (e.g. he just enjoys writing in Zig)
I wonder if there was just plain more love for Go than C# on the TypeScript team?
Alex Barnes (Mar 12 2025 at 22:20):Yes it had me puzzled why they would pick go too. But makes sense.
There was large part of the transcript in this Reddit post. https://www.reddit.com/r/golang/comments/1j8shzb/microsoft_rewriting_typescript_in_go
It read really well and makes a lot of sense.
Daniel Buckmaster (Mar 13 2025 at 03:01):I'm pretty excited for this. In a large Vue codebase, my VS Code intellisense is basically useless. Here's hoping we get a speed bump out of this. Of course, we are also behind on moving to Vite from Webpack so that might help too, but I'm not sure how much that has to do with the IDE performance.
Daniel Buckmaster (Mar 13 2025 at 03:02):I'm pretty surprised how much confusion there was about compiler performance versus runtime performance. I guess I just live and breathe this stuff, and there are lots of people seeing this who don't write TypeScript every day. On the other hand, people wishing for a "real TypeScript runtime" or "compiling TypeScript to native code" or "optimising TypeScript using its types" has been a persistent meme with little backing in real projects.
Ron Waldon-Howe (Mar 13 2025 at 03:18):The main project I maintain at work is large enough that it takes a few seconds for go-to-definition to start working in a fresh editor/LSP process
But what I'm really looking forward to here is ESLint's performance when using it with the TypeScript plugin and enabling the linter rules that require the LSP service
valon-loshaj (Mar 13 2025 at 11:14):overall i think this is a great move for typescript. tsc sits in every dev’s workflow (at least the ones that work in ts). reducing this step in the workflow to something nominal is fantastic.
regarding the confusion around runtime and compilation time, my thought is people are reading the headlines and not the details of the announcement. i saw quite a few headlines in my news feed saying things like “typescript just got 10x faster” which is a bit misleading.
lesson to anyone baited by headlines, always read the post and assume the title is mainly written to lure you in and drive the click :wink:
Ron Waldon-Howe (Mar 13 2025 at 20:37):It seems like a big part of the speed up here is being able to process files concurrently
And Node.js does have threads, but I assume the next problem after that is sharing data between threads in an efficient and safe manner
Daniel Buckmaster (Mar 14 2025 at 04:07):RE performance, Axel has a pretty good summary in this section of his article: https://2ality.com/2025/03/typescript-in-go.html#where-does-the-10%C3%97-speedup-come-from%3F
Daniel Buckmaster (Mar 14 2025 at 04:08):Node has pretty good primitives for message passing between threads, but not for shared memory.
valon-loshaj (Mar 14 2025 at 12:07):to implement multi-threading natively with javascript there would be too many changes required. between the event loop and object access it’s hard to see a path to a multi-threaded future for javascript natively.
however, it wouldn’t be impossible to imagine an abstraction layer for javascript that could support multi-threading (there are already a few oss libraries out in the wild that do a version of this).
one thing’s for sure, javascript gets so much love, has such a strong community and now with the assistance of gen-ai it’s only a matter of time before we start seeing some huge leaps forward in programming language performance….or maybe i’m just being overly optimistic :sweat_smile:
Tim Uckun (Mar 14 2025 at 20:56):Personally I think typescript goes overboard but there is no reason why somebody can't build a proper compiler for it. Not a transpiler to JS but an actual compiler.
That's what Mojo is doing with python.
Then again with the rise of AI I think somebody will make a language specific for AI. Something that may be difficult for humans to deal with but trivial for AI but one which can be proven to bug free at runtime. Something like elm or coq or one of those super strict provable languages.
The AI will spit out the code and will run it through the prover and on the other end you'll be assured it's solid code that won't blow up.
Ron Waldon-Howe (Mar 14 2025 at 23:03):I would love TypeScript so much more if there was a way to disable all the little compromises it makes in order to be compatible with JavaScript
Tim Uckun (Mar 15 2025 at 20:35):Honestly I just want somebody to make the crystal tooling better. It's such a nice language but the tooling and the compiler suffers which hinders wider adoption and vibrant community.
Ron Waldon-Howe (Mar 16 2025 at 00:37):I've certainly been spoiled by Rust and Go and other modern and well-furnished languages
It's hard for me to consider adding a language to my toolbox if it doesn't have:
valon-loshaj (Mar 16 2025 at 00:54):listened to the 2015 interview with anders… @Jerod Santo sounded like he was a typescript fan at a couple moments in the interview :face_with_hand_over_mouth:
Jerod Santo (Mar 16 2025 at 13:15):That was back before I was contractually obligated to hate it :wink:
valon-loshaj (Mar 16 2025 at 15:00):is there a plan to have anders on the pod again soon given the recent go rewrite?
beyond the go rewrite, would love to hear he perspective on the state of open source in this new gen-ai age.
Yawar Amin (Mar 16 2025 at 19:34):So, this is obviously very exciting, a 10x improvement in performance is going to save a TON of CI minutes and money for people. this is unambiguously good. in fact, this single port is probably going to save a ton of carbon emissions from happening to, probably far more than most people who talk about doing fancy stuff with programming language power efficiency.
Yawar Amin (Mar 16 2025 at 19:37):something that i find kind of amusing about TypeScript is that out of the AltJS compilers, it's been the odd one out by being implemented in itself. Flow is implemented in OCaml; ReScript is in OCaml; Gleam is in Rust; Elm and PureScript are in Haskell. and looking at Flow, which is the closest direct TypeScript alternative, it has evolved specialized techniques–like interface files–for speeding up compilation at Facebook/Meta scale.
Yawar Amin (Mar 16 2025 at 19:38):TypeScript is kind of playing catch-up now with the Go port
Tim Uckun (Mar 16 2025 at 20:56):@Ron Waldon-Howe
These days if you are writing a language start with the tooling first.
The go tooling is first rate (except for package management) but the language could use quite a bit of improvement.
Ron Waldon-Howe (Mar 16 2025 at 21:05):@Tim Uckun yeah, the tooling is terrific
Go loses points for me because of governance (the go.mod debacle), the lack of data-race safety, and how confusing/magical/inconsistent it is in the name of "simplicity"
Tim Uckun (Mar 16 2025 at 21:07):I have a long list of gripes against go the language. As I mentioned before Crystal is a much better language and fixes most if not all of them. Governance of Crystal is a bit insular though. The core team hasn't been all that great at building a community.
Brett Cannon (Mar 17 2025 at 20:31):For anyone else looking for the original link: https://devblogs.microsoft.com/typescript/typescript-native-port/
Last updated: Apr 03 2025 at 23:38 UTC