30 ms·

A 10x Faster TypeScript

• emcell 2y ago
  this is huge! thank you!
• aklein 2y ago
  Can’t wait for a better TSC Doom framerate.
• dimitropoulos 2y ago
  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/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!
  • troupo 2y ago
    > The TypeScript compiler relies on garbage collection in multiple places What? And how? And how would that help in Go which has a completely different garbage collection mechanism?
    • tgv 2y ago
      As in: there's no allocation/deallocation code. The code relies on garbage collection to function.
  • pansa2 2y ago
    > I was very surprised to see that the TypeScript team didn’t choose Rust Typescript is a Microsoft project, right? I’m surprised they didn’t choose C#.
    • jasonthorsness 2y ago
      Especially given Anders is the one announcing this, given he was the chief architect of C#. But C# AOT is maybe not as mature/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 https://github.com/microsoft/typescript-go/discussions/411 https://github.com/microsoft/typescript-go/discussions/411]
    • dimitropoulos 2y ago
      he went into the C# question in more detail this interview: https://youtu.be/10qowKUW82U?t=1154s https://youtu.be/10qowKUW82U?t=1154s
  • ChocolateGod 2y ago
    imho Go is a far easier language to learn than Rust, so it lowers the barrier to entry for new contributors.
    • rickette 2y ago
      Which is a massive pro for any open source project
• DanRosenwasser 2y ago
  Hi folks, Daniel Rosenwasser from the TypeScript team here. We'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.
  • loevborg 2y ago
    Congrat on the announcement, this is a great achievement!
  • dimitropoulos 2y ago
    thank you, to both of you, for so many years of groundbreaking work. you've both been on the project for, what, 11 years now? such legends.
  • jherdman 2y ago
    I'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?
  • eknkc 2y ago
    I feel like you'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'd like to see it in Rust but I'm still glad you went with Go. Are there any insights on the platform decision?
    • jchw 2y ago
      Honestly, the choice seems fine to me: the vast majority of users are not compiling huge TypeScript projects in the browser. If you're using Vite/ESBuild, you're already using a Go-based JS toolchain, and last I checked Vite was pretty darn popular. I don'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't, it should be more than fine for playground anyways.)
• bcherny 2y ago
  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.
  • pjc50 2y ago
    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.
    • bloomingkales 2y ago
      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'd have to be rendering straight to canvas/webgl for me to believe any of this.
    • austin-cheney 2y ago
      First, this thread and article have nothing to do with language and/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'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.
• presentation 2y ago
  Ive been dreaming about this for years! Never been so pumped.
• pseudopersonal 2y ago
  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 "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."
  • kaoD 2y ago
    To clarify why it'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's case, V8). It'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't and I don't think there's any in the works (or if that's even possible while maintaining runtime soundness, considering you can "lie" to TS by casting to `unknown` and then back to any other type).
    • seanmcdirmid 2y ago
      > It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further Typescript'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.
    • pseudopersonal 2y ago
      Thanks for the clarification. For those of us who don't use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn't know if it's about a compiler or a runtime. What if they announced a bun competitor? https://betterstack.com/community/guides/scaling-nodejs/nodejs-vs-deno-vs-bun/ https://betterstack.com/community/guides/scaling-nodejs/node....
      • internetter 2y ago
• joewood1972 2y ago
  One question that springs to mind is the in-browser "playground" and hosted coding use-case. I assume WASM will be used in that scenario. I'm wondering what the overhead is there.
  • ivanjermakov 2y ago
    Main overhead is shipping Go's WASM runtime to the client
• pjmlp 2y ago
  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't go with AOT compiled .NET, though.
  • pjc50 2y ago
    > Pity that they didn'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#)
    • atonse 2y ago
      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.
    • pjmlp 2y ago
      All Azure contributions to CNCF are using a mix of Go and Rust, mostly. Here is a kind of weird, given the team.
    • nwah1 2y ago
      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.
      • dagw 2y ago
        Hejlsberg seemed quite negative when it came to cross platform AOT compiled C# in several comments he's made, hinting at problems with both performance and maturity on certain platforms.
• electroly 2y ago
  I wonder, for a Microsoft project, why not C#? Would have been a nice win for the home team.
  • pier25 2y ago
    Anders explain why Go in this podcast: https://youtu.be/ZlGza4oIleY?t=1005 https://youtu.be/ZlGza4oIleY?t=1005
    • dagw 2y ago
      TL:DR; - Native executable support on all major platforms - He doesn'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
      • ramon156 2y ago
        So wild that most of these points were something C# was supposed to be good at, and they all boil down to "its just not as good in C# as in Go"
        • dagw 2y ago
          Yea, sounds like cross platform AOT compiled C# not being mature and performant was a big reason that C# was rejected. One other thing I forgot to mention was that he talked about how the current compiler was mostly written as more or less pure functions operating on data structures, as opposed to being object oriented, and that this fits very well with the Go way of doing things, making 1:1 port much easier.
          • pier25 2y ago
            > sounds like cross platform AOT compiled C# not being mature and performant was a big reason I don't think it was the performance. C# is usually on par or faster than Go. Could be the lack of maturity but also that I believe Go produces smaller binaries which makes a lot of sense for a CLI.
• tosh 2y ago
  tl;dr: TypeScript compiler (!) was implemented in TypeScript, new one is in Go half of the perf gain is from moving to native code, other half is from concurrency
• eapriv 2y ago
  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).
  • akmittal 2y ago
    TypeScript compiler is more of a transpiler, not a typical compiler that creates a binary. I don't think it was weird choice.
  • pjmlp 2y ago
    Bootstraping compilers is a common activity and TypeScript is a nice language.
    • nailer 2y ago
      Yep. I remember years ago when they celebrating getting the C# compiler working in C#.
      • atonse 2y ago
        That was the Roslyn project! Yes they were also excited that it would allow more devs to hook into the computer and also enhance it.
    • eapriv 2y ago
      “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.
  • ivanjermakov 2y ago
    I don't consider it strange, and I'm not alone: https://news.ycombinator.com/item?id=37171801 https://news.ycombinator.com/item?id=37171801
  • uncenter 2y ago
    is it not common to write compilers for languages in the language being compiled itself? rust does this i think?
• thund 2y ago
  Too bad they didn’t choose Rust, would have loved contributing (not picking up Go, sry)
  • dimitropoulos 2y ago
    did you contribute to the current TypeScript codebase? (not intended snarky, just curious)
    • thund 2y ago
      a couple of commits merged yrs back, things I stumbled on that I used as an excuse to learn more about internals
• wesbos 2y ago
  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 → https://www.youtube.com/watch?v=ZlGza4oIleY https://www.youtube.com/watch?v=ZlGza4oIleY
• algorithmsRcool 2y ago
  I am actually shocked that Anders chose Go over C# for this port.
• vivzkestrel 2y ago
  Has there been any talks/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
  • progmetaldev 2y ago
    There is this with does not do type checking: https://devblogs.microsoft.com/typescript/announcing-typescript-5-8/#the---erasablesyntaxonly-option https://devblogs.microsoft.com/typescript/announcing-typescr... This will only allow you to run your TypeScript in Node, but does not perform type checking, and I don't believe has any plans to. This is from Node.js 23.9.0 https://nodejs.org/api/typescript.html#type-stripping https://nodejs.org/api/typescript.html#type-stripping I don't believe Node has any plans for type checking TS.
• steve_adams_86 2y ago
  Syntax podcast has a conversation with Anders and Dan about it here: https://www.youtube.com/watch?v=ZlGza4oIleY&t=1s https://www.youtube.com/watch?v=ZlGza4oIleY&t=1s
  • mcintyre1994 2y ago
    Ah that'll be the thing Wes was under NDA about and teasing how excited he was on twitter last week!
    • wesbos 2y ago
      haha yep, everyone thought it was related to Vite. which I guess I kinda is?
      • steve_adams_86 2y ago
        I was hoping for something related to vacuums, but this is great too
• jbverschoor 2y ago
  Performance is a feature
• grantwu 2y ago
  > 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 resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable. --https://github.com/microsoft/typescript-go/discussions/411 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?
  • jchw 2y 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. To be fair, they didn't actually say that. What they said was that idiomatic Go resembles their existing patterns. I'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'd and don'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'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't resemble typical TypeScript isn't too surprising. Compilers written in Go also don't tend to resemble typical Go either, in fairness.
• rvz 2y ago
  So in order to get "Faster TypeScript" you have to port the existing "transpiler" 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.
  • Cthulhu_ 2y ago
    They're not getting "faster typescript", they're getting "a faster typescript transpiler / type checker"; subtle but important difference. The runtime of TS is Javascript engines, and most of "typescript transpilation" 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.
• adriancooney 2y ago
  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's Typescript.
  • slackerIII 2y ago
    Yes, 100% agree. We've spent so much time chasing down what makes our build slow. Obviously that is less important now, but hopefully they've laid the foundation for when our code base grows another 10x.
• slackerIII 2y ago
  This is amazing. Everyone that picked TS for a big project was effectively betting that someone would do this at some point, so it's incredible to see it finally happen. Thanks to everyone involved!
• ragnese 2y ago
  But, I was told that programming language choice doesn't matter and that I can write slow/bad code in any language... /s
  • dagw 2y ago
    You can write slow code in any language, but you cannot write fast code in any language.
    • ragnese 2y ago
      I didn't include every variant I've ever read, but there have been no shortage of people saying that the only thing that matters is your algorithms. Every time I've said that languages like Python, JavaScript, and basically any other language where it's hard to avoid heap allocations, pointer chasing, and copious data copies are all slow, there are plenty of people who come out of the woodwork to inform me that it's all negligible.
      • dagw 2y ago
        no shortage of people saying that the only thing that matters is your algorithms. To be a little bit fair to those people, I have been in many situations where people go "my matlab/python code is too slow, I must re-write it in C", and I've been able to get an order of magnitude improvement by re-writing the code in the same language. Hell I've ported terrible Fortran code to python/numpy and gotten significant performance improvement. Of course taking that well written code and re-writing that in well written C will probably give you a further order of magnitude improvement. Fast code in a slow language can beat slow code in a fast language, but obviously never beat fast code in a fast language.
        • ragnese 2y ago
          For sure. I agree with everything you say, and I've experienced the same thing 100 times, myself--including the specific scenario of speeding up someone's MATLAB code by multiple orders of magnitude by vectorizing the crap out of it. People seem to be almost drawn to quadratic-or-worse algorithms, even when I'd expect them to know better. I'm just a little bitter because of how many times I've been shushed in places like programming language subreddits and here when I've pointed out how inefficient some cool new library/framework/paradigm is. It feels like I'm either being gaslit or everyone else is in denial that things like excessive heap allocations really do still matter in 2025, and that JITs almost never help much with realistic workloads for a large percentage of applications.
• zidad 2y ago
  And the lesson is; don't build anything that needs to be performant in TypeScript because it's so slow?
  • rvz 2y ago
    Correct.
• 0xcb0 2y ago
  After years of PHP, I came to typescript nearly 4 years ago (for web front and backend development). All I can say is that I really enjoy using this programming language. The type system is just about enough to be helpful, and not too much to be in your way. Compiling the codebase is quite fast, compared to other languages. With a 10x, it will be so much fun to code. Never been a big fan of MS, but must say that typescript is well done imho. thanks for it and all the hard work!
  • zem 2y ago
    microsoft has historically been great at programming languages. qbasic, visual basic, c#, and f# are all excellent.
• pizlonator 2y ago
  Misleading title. TypeScript isn't getting 10x faster. The compiler is 10x faster.
  • tobyhinloopen 2y ago
    TS is nothing but a compiler
    • cjbgkagh 2y ago
      It compiles to JS, one possible read would be that TS compiles to JS which runs 10x faster due to optimizations that can be made.
      • alexanderchr 2y ago
        would be some very wishful reading!
• eboye 2y ago
  [dead]
• deleted 2y ago
  [deleted]
• ethan_smith 2y ago
  Wow, this is huge! A 10x speedup is going to be game-changing for large TypeScript codebases like ours. I've been waiting for something like this - my team's project takes forever to typecheck on CI and slows down our IDE. 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.
• kopirgan 2y ago
  Interesting Microsoft using Golang for this!
• dimgl 2y ago
  I'm really surprised by this visceral reaction to not choosing Rust. Go is a great language and I'd choose it for a majority of projects over Rust just based off of the simplicity of the language and the ability to spin up developers on it quickly. Microsoft is a big corporation. Why _not_ use Go?
  • homebrewer 2y ago
    > Why _not_ use Go? Because of its truly primitive type system, and because Microsoft already has a much better language — C#, which is both faster and can be more high level and more low-level at the same time, depending on your needs. I am a complete nobody to argue with the likes of Hejlsberg, but it feels like AOT performance problems could be solved if tsc needed it, and tsc adoption of C# would also help push C#/.NET adoption. Once again, Microsoft proves that it's a bunch of unrelated companies at odds with each other.
    • 9rx 2y ago
      > Because of its truly primitive type system That is the main reason they gave for why they those chose Go. The parent asked "Why _not_ use Go?"
      • subarctic 2y ago
        So they like having all the footguns?
        • 9rx 2y ago
          It was stated from the angle of wanting to ship software sometime this century. But there is probably some truth in what you say as well. Footguns are no doubt refreshing after being engrossed in Typescript (and C#) for decades. At some point you start to notice that your tests end up covering all the same cases as your advanced types, and you begin question why you are putting in so much work repeating yourself, which ultimately sees you want to look for better. Which, I suppose, is why industry itself keeps ending up taking that to the extreme, cycling between static and dynamic typing over and over again.
• Delomomonl 2y ago
  I don't get it. Why is typescript not already a standard natively supported by browers?!
  • Cthulhu_ 2y ago
    It kinda is already; strip type information and you've got valid JS. NodeJS supports running Typescript nowadays with the exception of some uneraseable syntax that is being discouraged, I'm sure it's only a matter of time before that bubbles up to V8 and other browser JS engines.
• localghost3000 2y ago
  Something that kind of got understated in here IMO is the improved refactoring and code intelligence that this will unlock. Very exciting! I am looking forward to all the new tooling and frameworks that come out of this change. TS is already an amazing language and just keeps getting better!
  • ilrwbwrkhv 2y ago
    From the post: > Modern editors like Visual Studio and Visual Studio Code have excellent performance. Well I am not sure we are on the same page here. Still, fingers crossed.
• dev1ycan 2y ago
  Typescript is a nice programming language, Javascript is not, I am glad
• reverseblade2 2y ago
  Just use fable and F# instead, your code transpiles to python and rust too
  • aaronmu 2y ago
    For the small price of 10x slower tooling. I’ve been using F# full-time for 6 years now. And compiler/tooling gets painfully slow fast. Still wouldn’t trade it for anything else though.
• zerr 2y ago
  Use browser and web for websites, not applications. For apps, create native downloadable desktop software, which also work offline.
  • kridsdale1 2y ago
    I work at Google (the original and worst offender of this) and I advocate for native binaries all the time.
  • butshouldyou 2y ago
    Funnily enough, that's exactly what they're doing in this announcement. They're rewriting `tsc` in Go and shipping native binaries, rather than shipping JS.
    • zerr 2y ago
      Didn't quite get, they compile ts to js using the compiler now written in Go, right? But we as end users still get js, not a native app.
  • ggregoire 2y ago
    I prefer having all my apps in the browser.
  • deleted 2y ago
    [deleted]
• deleted 2y ago
  [deleted]
• Starlord2048 2y ago
  [flagged]
  • ninetyninenine 2y ago
    I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.
    • michaelsbradley 2y ago
      It’s not popular compared to Go/Rust, but many find Nim scratches that itch: https://nim-lang.org/ https://nim-lang.org/
      • pclmulqdq 2y ago
        Zig is another popular neo-language in the same rough space.
    • sapiogram 2y ago
      Rust loses a lot of its nice properties without borrow checking and lifetimes, though. For example, resources no longer get cleaned up automatically, and the compiler no longer protects you against data races. Which in turn makes the entire language memory unsafe.
      • throw-the-towel 2y ago
        OTOH it would still have Rust's sane type system and all the nice features it makes possible.
        • nine_k 2y ago
          OCaml and Haskell already have that nice type system (and even more nice). If OCaml's syntax bothers you, there is Reason [1] which is a different frontend to the same compiler suite. Also in this space is Gleam [2] which targets Erlang / OTP, if high concurrency and fault tolerance is your cup of tea. [1]: https://reasonml.github.io/ https://reasonml.github.io/ [2]: https://gleam.run/ https://gleam.run/
• DanielHB 2y ago
  Any plans for a AOT version of Typescript with strict typing that targets WASM or LLVM?
  • Ciantic 2y ago
    This is what I would have liked too: Figure out a sufficient subset of TypeScript that can be compiled to native/WASM and then write TSC in that subset. While I like faster TSC, I don't like that the TypeScript compiler needs to be written in another language to achieve speed; it kind of reminds everyone that TS isn't a good language for complicated CPU/IO tasks. Given that the TypeScript team has resigned to the fact that JavaScript engines can't run the TypeScript compiler (TSC) sufficiently fast for foreseeable future and are rewriting it entirely in Go, then it is unlikely they will seek to do AOT.
    • pjmlp 2y ago
      This already exists, Static TypeScript https://makecode.com/language https://makecode.com/language https://www.microsoft.com/en-us/research/publication/static-typescript/ https://www.microsoft.com/en-us/research/publication/static-...
      • DanielHB 2y ago
        If it is not supported by the same team that supports typescript it is not really usable in real world applications.
        • pjmlp 2y ago
          I guess the same applies for using Go then.
  • spankalee 2y ago
    If you squint, Porffor[1] might end up being something like that. It doesn't use type hints yet, and the difficulty there is that you'd need a sound type system in order to rely on the types. You may be able to use type hints to generate optimized and fallback functions, with type guards, but that doesn't exist yet and it sounds like the TypeScript team wants to move pretty quickly with this. [1]: https://porffor.dev/ https://porffor.dev/
• register 2y ago
  I really wonder why this project have not been developed in .NET core. I would have then been possible to embed this in .NET projects increasing the available number of libraries in the ecosystem. Also it woul have leverages .NET GC which is better than Go. Rewriting in Go really doesn't make sense to me.
• zoogeny 2y ago
  I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. 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.
  • sapiogram 2y ago
    > 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. Software never gets rewritten in a higher level language, but software is constantly replaced by alternatives. First example that comes to mind is Discord, an Electron app that immediately and permanently killed every other voice client on the market when it launched.
    • wrs 2y ago
      It’s a little more nuanced though — I doubt the audio processing in Discord is written in JavaScript. (But I haven’t looked!)
• alberth 2y ago
  Dumb question: is this a 10x speed up in the run-time of TypeScript ... or just the build tooling? 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)
  • jakebailey 2y ago
    This is specifically about the performance of the TypeScript toolchain (compiler, editor experience); the runtime code generated is the same. TypeScript is just JS with types.
  • LVB 2y ago
    Just building (and supporting features like LSP)
  • Tadpole9181 2y ago
    There is no Typescript runtime, it's just a transpiler.
• sesm 2y ago
  Kinda shows that there is no practical ML-family language with good concurrency support.
  • nipah 2y ago
    Don't think so, he stated one of the most important reasons was code compatibility, not specifically a good concurrency support (but this was important, indeed). I think even the most functional languages would not be easily compatible with "functional typescript code" without hard modifications. But either way, there is space for innovation in the field, I'm yet to see a ML-family language with concurrency that is as "hands on" as Go is, it would be extremely interesting to see this happening.
• cjbgkagh 2y ago
  My read on why Go and not AOT C# is it would be more difficult to get a C# programmers to give up idiomatic OOP in C# than it would be to get C# programmers to switch to Go. Go is being used as a forcing function to push dev cultural change. This wouldn't generalize to teams that have other ways of dealing with cultural change.
• melodyogonna 2y ago
  Oh man, this is great. I've been having performance issues with TSC for language services. 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.
• DrBenCarson 2y ago
  I get that the choice was well thought out, but it would have been nice to use the same language as most of the modern tools (Rust) Do any other well-adopted tools in the ecosystem use Go?
  • homebrewer 2y ago
    > other well-adopted tools in the ecosystem use Go esbuild is the most well-known/used project, probably beats all other native bundlers combined. I can't remember anything else off the top of my head. https://github.com/evanw/esbuild https://github.com/evanw/esbuild
• garbagepatch 2y ago
  What do they mean by improving editor startup time? Does the editor (I assume vscode?) run the compiler as part of the startup? Why?
  • gavmor 2y ago
    There are various ways to (de)couple the compiler to/from vscode, but it's definitely handy to have inline typechecking. Is this possible without running the compiler?
  • wiseowise 2y ago
    How would they show syntax highlighting otherwise?
    • Cthulhu_ 2y ago
      regexes, generally.
  • desumeku 2y ago
    The language server, maybe?
• atak1 2y ago
  Curious how this is going to affect Cursor - I'm assuming it'll just be a drop-in replacement and we can expect Cursor to get the same speed-up as VSCode.
• _benton 2y ago
  > ctrl-f "rust" > 93 matches sigh
• DrammBA 2y ago
  People seem very hurt that the creator of C# didn't pick C# for this very public project from a multi-trillion-dollar corp. I find it very refreshing, they defined logical requirements for what they wanted to do and chose Golang because it ticked more boxes than C#. This doesn't mean that C# sucks or that every C# project should switch to Golang, but there seems to be a very vocal minority affected by this logical decision.
  • bitmasher9 2y ago
    My favorite benefit of Go over C# is that I don’t have to carry around a dotnet runtime to every service that touches my Typescript code.
    • nailer 2y ago
      Can't the CLR tools just output native binaries now?
      • bitmasher9 2y ago
        Can it? That’s awesome. Mostly these days I’m only aware of C# when it inconveniences me.
        • ryoukokonpaku 2y ago
          It even produces smaller binaries than Go and the size scales much better as the codebase grows too. dotnet has come a long way since the olden days of .net framework. The reasons stated on github doesn't seem to be convincing imo. - platform support NativeAOT supports all platforms, the only one missing is Android which is marked experimental, but since they'd be treated as a "1st party" customer since they're both MS projects, this could be easily expedited. Even WASM is supported in NativeAOT using the LLVM toolchain and is often compared to perform better than Go's WASM target which doesn't use LLVM - Usage of functions and structs C# supports this, and you even have better control on layout and performance in this regard. Functions can easily be ported as static functions on static classes. They could even use F# which is even closer to Typescript if they wanted a more direct port as both languages compile to IL for NativeAOT. There must be more reasons as to why it didn't choose C# in this regard, likely non-technical related. A missed opportunity imo.
• gwbas1c 2y ago
  This is frustrating: > 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.
  • lenkite 2y ago
    Better a language that deprecates and breaks things at regular intervals of time compared to a language that has Forever Backward Compatibility like C++ and evolves into a mutated, tentacled monster that strangles developers who are trying to maintain a project.
  • brokencode 2y ago
    Yeah, this is not ideal. I’m hoping that the breaking changes don’t affect the code at my work, since we also had to spend multiple years on a major .NET Core transition. I want the faster compiles right away, not in a few years.
  • kansface 2y ago
    I lived and worked through the Python 2->3 fiasco, working on a Python library that had to run on both versions. I have since abandoned the language. Python3 was both slower and and not backwards compatible whereas TSC 7 is 10x faster and uses half the memory. I'm not worried.
  • ricardobeat 2y ago
    This is mostly about the tooling and ecosystem, they want to stop things from depending on the internal workings of the compiler. If you just want to write and compile TS you'll be fine, it does not mean breaking changes to actual TypeScript grammar.
• subarctic 2y ago
  One question I'm surprised isn't discussed here is how much AI code generation was used in this port. It seems like the perfect use case for it.
• trashface 2y ago
  I can see why they didn't use Rust, I've written little languages in that myself, so I know what is involved, even though I like the language a lot. But I'm quite surprised they didn't use C#. I would have thought ahead-of-time optimized C# would give nearly the same compilation speed as Go. They do seem to be leaning into concurrency a lot so maybe its more about Go's implementation of that (CSP-like), but doesn't .Net have a near-equivalent to that? Have not used it in a while. 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#discussioncomment-12464695 https://github.com/microsoft/typescript-go/discussions/411#d...
• nailer 2y ago
  Keep in mind most apps made in frameworks aren't using `tsc` but rather existing tools like `esbuild` which are native binaries.
  • sethaurus 2y ago
    That's true of the compilation step, but type-checking always uses `tsc`. They're no TS spec, so it's very hard to build a fully-compatible competing implementation. Erasing the types syntactically is a lot easier.
• dustedcodes 2y ago
  Meanwhile .NET developers are still waiting for Microsoft to use their own "inventions" like Blazor, .NET MAUI, Aspire, etc. for anything meaningful. Bless them.
  • zuhsetaqi 2y ago
    Aspire is made with Blazor
  • Cthulhu_ 2y ago
    "anything meaningful"? Does this mean that those technologies aren't used for anything meaningful, or that you're simply not aware of them? (I'm simply not aware of them but that also means I won't make any statements about these)
  • lomase 2y ago
    Bing is made with ASP .net
  • Shocka1 2y ago
    Doesn't matter. Some could care less what MSFT is doing - a Blazor app I developed in super-speed time has collected 40k transactions in the last 4 months. It did it's job.
• kevlened 2y ago
  For previous attempts at a faster tsc, but in rust, see: 1. https://github.com/dudykr/stc https://github.com/dudykr/stc - Abandoned (https://github.com/swc-project/swc/issues/571#issuecomment-1915966297 https://github.com/swc-project/swc/issues/571#issuecomment-1...) 2. https://github.com/kaleidawave/ezno https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.
  • smarx007 2y ago
    I think Deno and Bun are the two successful attempts at a faster tsc :)
    • keturakis 2y ago
      Both Deno and Bun still use current tsc for type checking
    • madjam002 2y ago
      They just strip types and don’t do any type checking
    • Cthulhu_ 2y ago
      Those are runtimes primarily, not compilers/type checkers. Likewise, TSC is not a TS runtime.
      • smarx007 2y ago
        Well, of course. But TSC output (transpiled JS source code) is then run by a JS runtime like Node that has a VM like V8 that makes an internal representation for the JS code. Using Bun or Deno allows you to go to a VM IR from the TypeScript directly without a need for TSC transpilation into JS first. But as @keturakis pointed out (thanks!), Deno/Bun still rely on TSC, which I was not aware of.
        • morcus 2y ago
          Bun doesn't even support a way to check types, just remove them. > Note — Similar to other build tools, Bun does not typecheck the files. Use tsc (the official TypeScript CLI) if you're looking to catch static type errors.
• lxe 2y ago
  Why not just work with the SWC folks and get the Rust implementation mainlined?
  • spankalee 2y ago
    They want exact backwards compatibility with the JS implementation, so they're doing a lit-by-line port.
• darthrupert 2y ago
  This kinda begs the question: should we port all backend Typescript code to Go (or Rust) to get a similar runtime performance improvement? Is Typescript generally this inefficient?
  • airforce1 2y ago
    If your backend is JS and it's too slow for you, then obviously porting it to a machine code binary will speed it up significantly. If you are happy with your backend performance, then does it matter?
  • crabmusket 2y ago
    You could profile it and find out. Another commenter pointed out that compilers have very different performance characteristics to games, and I'll include web servers in that too. tsc needs to start up fast and finish fast. There's not a ton of time to benefit from JIT. Your server on the other hand will run for how long between deployments?
• haxiomic 2y ago
  Sounds like they're automatically generating Go code from ts in some amount [0]. I wonder if they will open the transpilation effort, in this way you'd create a path for other TypeScript projects to generate fast native binaries Opened discussion [1] - [0] https://github.com/microsoft/typescript-go/discussions/410 https://github.com/microsoft/typescript-go/discussions/410 - [1] https://github.com/microsoft/typescript-go/discussions/467 https://github.com/microsoft/typescript-go/discussions/467
  • jakebailey 2y ago
    The automatic generation was mainly a step to help with manual porting, since it requires so much vetting and updating for differences in data layout; effectively all of the checker code Anders ported himself!
  • maxloh 2y ago
    It seems that they port the code manually, probably with the help of LLMs. https://github.com/microsoft/typescript-go/commits?after=dad5177643cd503e3ab2abe9f3ad46c0a035587f+344 https://github.com/microsoft/typescript-go/commits?after=dad...
• aiiizzz 2y ago
  So is the language server still not going to match lsp spec? Even though it's getting a complete rewrite?
• umvi 2y ago
  This is great news. We actually use esbuild most of the time to transpile TS files because tsc is so slow (and only run tsc in CI/CD pipelines). Coincidentally, esbuild is also golang
• stuaxo 2y ago
  I'd like to see if it makes a difference to the version of DOOM that runs in the TypeScript type system. https://news.ycombinator.com/item?id=43184291 https://news.ycombinator.com/item?id=43184291 https://www.youtube.com/watch?v=0mCsluv5FXA https://www.youtube.com/watch?v=0mCsluv5FXA
  • jack4818 2y ago
    Haha this was my first thought too
  • dimitropoulos 2y ago
    hi! author of the Doom thing, here. while I won't be the one to try, my answer is "absolutely yes, it will make a massive difference". Sub-1-day Doom-first-frame is probably a possibility now, if not much more because actually the thing that was the largest bottleneck for Doom-in-TypeScript-types was serializing the type to a string, which may well be considerably more than 10x faster. Hopefully someone will try some day!
    • Cthulhu_ 2y ago
      > Sub-1-day Doom-first-frame Love it :D
  • dlahoda 2y ago
    i guess they started rewrite exactly because of doom performance. timelines match.
• deskr 2y ago
  I'm sold. 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.
  • deleted 2y ago
    [deleted]
• odyssey7 2y ago
  The key: > 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 https://youtu.be/pNlq-EVld70?feature=shared&t=522
• falleng0d 2y ago
  I wonder how much faster DOOM will run on this
• massive-fail 2y ago
  Typescript was the best thing that ever happened to the web! Thanks Daniel, Ryan and Anders and the rest of the team for making development great for over 10 years! This improvement is amazing!
  • nonethewiser 2y ago
    >Typescript was the best thing that ever happened to the web! My development in regards to language: - Javascript sucks I love Python. - Python sucks I love Typescript.
• lawls 2y ago
  still javascript though
• tomatofrank 2y ago
  Very pumped to see how this improves the experience in VSCode. 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.
  • efields 2y ago
    Sublime Text has been my main since at least then as well. I can _see_ the lag in VSCode.
  • crabmusket 2y ago
    > Not sure how this announcement impacts VSCode's UI being powered by Electron It has no bearing on this at all.
• tracker1 2y ago
  Given the direction and efforts into projects like rspack, rolldown, etc. Why were they not considered as possible collaboration projects or integrations for this? 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.
• robinsonrc 2y ago
  Sad to see them using Go and not Anders’s own language (Turbo Pascal 7) for this
  • whattidywhat 2y ago
    There should be an award for this comment.
• Traubenfuchs 2y ago
  I wonder how much that would have helped the guy who implemented Doom in TS types only.
• g0ld3nrati0 2y ago
  Will TS v7 only support erasable syntax? e.g. no enums?
  • progmetaldev 2y ago
    TS v5.8 added the --erasableSyntaxOnly option, along with Node.js 23.6 so you can run your TS in Node, which will error on enums (as well as namespaces and other syntax). I haven't found anything that mentions the deprecation of enums when searching, TS v6 is supposed to be as feature compatible with v7 as possible, and since enums are not a type-level feature of JS I wouldn't rely on them. Right now you can make use of the --erasableSyntaxOnly to find any enums in your code, and start porting over to an alternative. This article lists alternatives if you're interested. https://exploringjs.com/tackling-ts/ch_enum-alternatives.html https://exploringjs.com/tackling-ts/ch_enum-alternatives.htm...
• paxys 2y ago
  Faster compilation is great, but what I'm really excited for is a faster TS Language Server. Being able to get autocomplete hints, hover info, goto definition, error squiggles and more anything close to 10x faster is going to be revolutionary when working in large TS codebases.
• hamandcheese 2y ago
  I love all this native tooling for JS making things faster. 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).
  • unilynx 2y ago
    Even if they freeze typescript development after the native implementation, given that the current performance was apparently acceptable to the current users, type complexity will just grow to use up the headroom Plus, using TS directly to do runtime validation of types will become a lot more viable without having to precompile anything. Not only serverside, we'll compile the whole thing to WASM and ship it to the client to do our runtime validation there.
• alexisread 2y ago
  1ct5 44t t5
• synergy20 2y ago
  In Golang, wow. That gives me more confidence to adopt Go in projects.
• CLiED 2y ago
  Few things are more Microsofty than a team reaching over to a competitor's language instead of using their own and to boot none of the reasons given so far seem credible, good job to the team nonetheless.
  • sesm 2y ago
    Totally agree about reasons, they have some hidden agenda behind this decision that they don't want to disclose. Rewriting in native code allows step-by-step rewrite using JS runtime with native extensions, but moving to a different VM mandates big rewrite. My most plausible guess would be that compiler writers don't want to dig into native code and performance, writing a TS to Go translator looks like a more familiar task for them. Lack of JS version performance analysis anywhere in the announcements kinda confirms this.
  • Cthulhu_ 2y ago
    I think it's a mature decision, besides, Go is an open source project, calling it "a competitor's language" is a bit derisive. The developers behind Go, Typescript, C#, etc were designing languages well before they were hired by those companies, I don't think they consider their languages a "google" or "microsoft" specific language per se.
• skwee357 2y ago
  “Developers rewrite tools from dynamic language to statically compiled one - improves performance by 10x” Also, what’s up with 10x everywhere? Why not 9.5x or 11x?
  • Cthulhu_ 2y ago
    If you want to be pedantic, the benchmarks they ran showed speedups of 10.4x, 10.1x, 13.5x, 9.5x, 9.1x and 11.0x, for an average of 8.95x.
• singularity2001 2y ago
  So now tsc is a binary, browsers can efficiently bundle it and compile index.ts on the fly ... please?
  • crabmusket 2y ago
    > browsers can efficiently bundle it That's really not what's stopping TS being built in to browsers. Have a look at the discussions around the types-as-comments proposal https://tc39.es/proposal-type-annotations/ https://tc39.es/proposal-type-annotations/
• 29athrowaway 2y ago
  tl;dr 10x faster compilation, not runtime performance
• srott 2y ago
  Funny, until now I always thought that TypeScript is JavaScript with some C# vibes https://news.ycombinator.com/item?id=43320086 https://news.ycombinator.com/item?id=43320086
  • Cthulhu_ 2y ago
    They're by the same guy, so that tracks. C# did a lot of groundwork for Typescript and other newer language's type systems, like Java did for C#.
• osigurdson 2y ago
  Why not Rust? https://youtu.be/10qowKUW82U?t=769 https://youtu.be/10qowKUW82U?t=769 Why not C#? https://youtu.be/10qowKUW82U?t=1155 https://youtu.be/10qowKUW82U?t=1155
  • deleted 2y ago
    [deleted]
• arrty88 2y ago
  Now make it executable in the go runtime please:)
• neycoda 2y ago
  Once people figure out how much faster their apps will be, they'll add enough features to slow it down again.
• Lanayx 2y ago
  [dead]
• accassar 2y ago
  What percentage of the new code was written by an LLM?
• goda90 2y ago
  This will be very welcome. I've been working on refactoring very large Typescript files in a very large solution in VS2022. Sometimes it gets into a state where just editing the code or copy/pasting causes it to hang for a few seconds and the fans on my workstation to take off like a jet engine. The typing advantages my team has gotten from migrating our codebase to Typescript has been invaluable, but the performance implications really hurt.
  • Cthulhu_ 2y ago
    It's the same with formatting and linting, I've heard some people mention long delays caused by eslint / prettier. Biome is faster for formatting, but the eslint plugin ecosystem is still too important for us to switch to Biome for linting as well.
• deleted 2y ago
  [deleted]
• zestyping 2y ago
  That's a pretty misleading clickbait title. TypeScript isn't getting 10x faster; the TypeScript compiler is getting 10x faster. 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.
  • campers 2y ago
    There isn't a TypeScript runtime, it is just a JavaScript/ECMAScript compiler/transpiler with a type checking and language server
  • salmonellaeater 2y ago
    My initial interpretation of the title was that the TS team was adding support for another, faster, target such as the .NET runtime or native executables. The title could use some editing.
  • Cthulhu_ 2y ago
    Yeah, it's a bit linkbaity as it implies that the runtime is 10x faster; just adding the word 'compiler' or 'type checker' to the title would fix it.
    • agos 2y ago
      There isn't a single runtime, it's quite clear that Typescript here means the compiler
• cytocync 2y ago
  [dead]
• jujadjwdfs 2y ago
  Not sure if this point was brought up but I think it's worth considering. 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.
  • neonsunset 2y ago
    Go is more vulnerable to thread starvation when you go across interop. If you do not, it has better scheduling fairness but is less efficient at firing off new short-lived goroutines than .NET is at tasks.
• Ericson2314 2y ago
  It should be in OCaml. This is why I think OCaml should be compilable to the Go runtime/ABI.
• gqgs 2y ago
  I guess this helps explain why Microsoft has their own fork on the Go language.
• sublinear 2y ago
  Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?
  • danielheath 2y ago
    > a significant performance penalty with typescript There's a significant performance penalty for using javascript outside the browser. I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. It's generally also very difficult to make a JS program as fast as even a naive go program, and the performance tooling for go is dramatically more mature.
    • sapiogram 2y ago
      > I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process. You haven't looked very hard then, NodeJS has supported worker threads for years. However, to uphold Javascript's safety guarantees, they can only communicate via message passing, or sharing a special `SharedArrayBuffer` datatype, neither of which are well suited to sharing large immutable data structures.
  • salmonellaeater 2y ago
    No. You seem to be referring to runtime performance of compiled code. The announcement is about compile times; it's about the performance of the compiler itself.
  • Cthulhu_ 2y ago
    Nope; 'compiling to javascript' is a relatively trivial operation, just remove the type information. This is what Babel and nowadays NodeJS itself are doing. What is more important is that tsc does typechecking, which is a static analysis of sorts to ensure code correctness. But this has nothing to do with runtime performance, that's entirely in JS land and in JS transpilers / optimizers.
• wodenokoto 2y ago
  So the end goal is that I can write a typescript application and deploy an executable to my server? Or is it just to deliver faster versions of typescript tools and MS developed typescript applications?
• DeathArrow 2y ago
  The news for me is Microsoft teams relying on Go. 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.
  • Cthulhu_ 2y ago
    That's not how open source works / should work though. If the Go maintainers (that happen to work at Go) ignore problems that the MS teams flag up, they can fork the language. The opposite would be true as well, teams at Google using Typescript or C# would rely on Microsoft to fix any issues.
  • leosanchez 2y ago
    > Now if they will have problems, they will depend on the Go team at Google to fix them. Or collaborate with Go team.
  • commandersaki 2y ago
    I know a few teams in Azure Networking teams that use Go. I don't think it's uncommon.
  • pjmlp 2y ago
    Actually, they have their own Go compiler. https://devblogs.microsoft.com/go/ https://devblogs.microsoft.com/go/ Just like they have their own Java distribution, after everything that caused C# to exist in first place, https://devblogs.microsoft.com/java/ https://devblogs.microsoft.com/java/ Yes, the new DevDiv is not like the Microsoft of old. But then the .NET team shouldn't be asking every now and then on social media, why other languages get chosen, outside the Windows ecosytem.
  • whoknowsidont 2y ago
    >Now if they will have problems, they will depend on the Go team at Google to fix them. MS literally already has a whole team around Go. And if they didn't, Go is completely open source. C# is open-source in name only.
• aib 2y ago
  Just tried it on our codebase. Getting over a thousand errors, a good portion of which seem to be: ../../../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"; ~~~~~~~ Probably an easy fix. 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.
  • yohannesk 2y ago
    If you are wondering why not Rust instead of Go, they outline why Rust was not chosen. This is a port not a reimplementation. Many of the data structures can not easily be ported to Rust, such as Nodes with cyclic dependencies. Check the longer interview here: https://www.youtube.com/watch?v=10qowKUW82U&ab_channel=MichiganTypeScript https://www.youtube.com/watch?v=10qowKUW82U&ab_channel=Michi... Also, I think the discussion on esbuild's choice of language applies here as well as it has a large similarity. You can find it here on hn
  • wiseowise 2y ago
    > 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. They would be still setting up the project, if it was Rust.
  • Cthulhu_ 2y ago
    It's very early days (perhaps too early?); running into issues caused by what very well may be an automated conversion is to be expected, and not down to the language choice. Why not find out what's going wrong and submit a bug report / merge request instead of immediately dismissing a choice made by one of the leading authorities in programming languages in the world?
• stef-13013 2y ago
  The main problem is that AOT C# is not as mature on platforms other than Windows, if that. So, to me, Hejlsberg's choice sounds pretty logical. After, why go ? why not...
• dlahoda 2y ago
  imho main reason for go is big pool of engineers to hire who have read this book set https://compilerbook.com/ https://compilerbook.com/ as i see next planned feature is macro in TS(joke, just because 3rd book is macro).
• NiloCK 2y ago
  One outsized impact of this is going to be on agentic LLM programming workflows, where compile and test time are trending toward being the dominant bottlenecks. See how many spaghetti types get churned through this faster transpiler. Didn't expect Jevons paradox popping up for compilers.
• zombot 2y ago
  No, it's not TypeScript that is 10 times as fast, only the TypeScript compiler. Bad title. Also, "10x faster" would be a factor of 11.
• whoknowsidont 2y ago
  I'm glad the team was able to pick something because it was a good fit for them and their goals, and not because of perception or love of some tech-stack. Programming languages are tools. Nothing more.
• maginx 2y ago
  I'm curious about the 10x via implementation in Go - couldn't it have been realized otherwise? Finding the hotspots, reimplementing them using better algorithms, if necessary move a few critical paths to native etc. Or even improving the JIT itself which might benefit all programs. Just wondering because I wouldn't think that the JIT-overhead was that much that you could gain 10x just reimplementing in Go (or C, assembly etc)... that is something I would only have expected if going from an interpreted context.
  • tefkah 2y ago
    hjalsberg has explained this in some interviews. roughly 3x speed up from going native, another 3-4x speed up from being able to actually do effective multi threading