A 10x Faster TypeScript

Post by merb » Tue, Mar 11, 2025, 9:22 PM UTC

jchw wrote: post #54

eknkc wrote: post #15

Earlier quoted context omitted.

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?

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 b…

Post by 999900000999 » Tue, Mar 11, 2025, 9:23 PM UTC

tonyhart7 wrote: post #515

999900000999 wrote: post #132

Earlier quoted context omitted.

I personally find Go miles easier than Rust. Is this the ultimate reason,Go is fast enough without being overally difficult. I'm humbly open to being wrong. While I'm here, any reason Microsoft isn't sponsoring a solid open source game engine. Even a bit of support for Godot's C#( help them get it working on web), would be great. Even better would be a full C# engine with support for web assembly. https://github.com/…

"any reason Microsoft isn't sponsoring a solid open source game engine" I can see they do this in the future tbh, given how large their xbox gaming ecosystem, this path is very make sense since they can cut cost while giving option to their studios or indie developers

Post by acomagu » Tue, Mar 11, 2025, 9:26 PM UTC

DanRosenwasser wrote: post #59

no_wizard wrote: post #42

Earlier quoted context omitted.

Like others I'm curious about the choice of technology here. I see you went with Go, which is great! I know Go is fast! But its also a more 'primitive' language (for lack of a better way of putting it) with no frills. Why not something like Rust? Most of the JS ecosystem that is moving toward faster tools seem to be going straight to Rust (Rolldown, rspack (the webpack successor) SWC, OXC, Lightning CSS / Parcel etc)…

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I'll post the response below. https://github.com/microsoft/typescript-go/discussions/411 . ____ Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a nativ…

Post by mappu » Tue, Mar 11, 2025, 9:27 PM UTC

zozbot234 wrote: post #438

airforce1 wrote: post #433

Earlier quoted context omitted.

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing. I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been ver…

I think the Wasm backends for both Golang and LLVM have yet to support the Wasm GC extension, which would likely be needed for anything like real parity with JS. The present approach is effectively including a full GC implementation alongside your actual Golang code and running that within the Wasm linear memory array, which is not a very sensible approach.

Post by reactordev » Tue, Mar 11, 2025, 9:31 PM UTC

999900000999 wrote: post #399

cardanome wrote: post #382

Earlier quoted context omitted.

> Even a bit of support for Godot's C#( help them get it working on web), would be great. They did that. https://godotengine.org/article/introducing-csharp-godot/ At least some initial grant to get it started. Getting C# working on web would be an amazing. It is already on the roadmap but some sponsorship would help tremendously for sure.

Ok. Credit where credit is due, but considering the sheer value of having the next general of programmers comfortable with .net, Microsoft *should* chip in more.