Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

Post reply on HN
Print view View original

591–600 of 943 posts

Re: A 10x Faster TypeScript

#591

Post by sesm »

CLiED wrote: post #544

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.

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.

Re: A 10x Faster TypeScript

#592

Post by zozbot234 »

mappu wrote: post #547
zozbot234 wrote: post #438

Earlier quoted context omitted.

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.

The major roadblocks for WasmGC in Golang at the moment are (A) Go expects a non-moving GC which WasmGC is not obligated to provide; and (B) WasmGC does not support interior pointers, which Go requires. https://github.com/golang/go/issues/63904#issuecomment-22536...

These are no different than the issues you'd have in any language that compiles to WasmGC, because the new GC'd types are (AIUI) completely unrelated to the linear "heap" of ordinary WASM - they are pointed to via separate "reference" types that are not 'pointers' as normally understood. That whole part of the backend has to be reworked anyway, no matter what your source language is.

Re: A 10x Faster TypeScript

#593

Post by vips7L »

pebal wrote: post #565
vips7L wrote: post #551

Earlier quoted context omitted.

On the topic of preference, this thread has really shown me that there is a HUGE preference for a native-aot gc language that is _not_ Go. People want AOT because of the startup and memory characteristics, but do not want to sacrifice language ergonomics. C# could fill that gap if Microsoft would push it there.

Just use the fast GC library in C++.

I don't think C++ has good language ergonomics.

Re: A 10x Faster TypeScript

#594

Post by [deleted] »

sebzim4500 wrote: post #496
austin-cheney wrote: post #254

Earlier quoted context omitted.

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

How do you reconcile this view with the fact that the typescript team rewrote the compiler in Go and it got 10x faster? Do you think that they could have kept in in typescript and achieved similar performance but they didn't for some reason?

[deleted]

Re: A 10x Faster TypeScript

#596

Post by zamalek »

jjice wrote: post #31
pjmlp wrote: post #12

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.

If I recall in an article from a while back, the idea was originally rust, but the current compiler design had lots of references shared references that would make the port to rust a lot of work.

He also mentioned doing a line-for-line port. Assuming you could somehow manage that, you'd probably end up with something slower than JS (not entirely a joke). I'm a rust fanboy, but have to concede that Go was the be t choice here.

If it was a fresh compiler then the choice would be more difficult.

Re: A 10x Faster TypeScript

#597

Post by pas »

kaoD wrote: post #10
pseudopersonal wrote: post #8

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…

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

I use TS a lot and still assumed they are embarking on a native runtime/compiler whatever epic journey.

Re: A 10x Faster TypeScript

#599

Post by vips7L »

almosthere wrote: post #523
electroly wrote: post #143

Earlier quoted context omitted.

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C# , given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?" C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed. C# has all that stuf…

.NET executables requires a runtime environment to be installed. Go executables do not. TSC is installed in too many places for that burden to be placed all of a sudden. It is the same reason why Java has had a complicated acceptance history too. It's fine in the places that it is pre-installed, but no where else. Node/React/Typescript developers do not want to install .net all of a sudden. If you react that poorly,…

.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.

Re: A 10x Faster TypeScript

#600

Post by [deleted] »

kaoD wrote: post #10
pseudopersonal wrote: post #8

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…

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

[deleted]
Post reply on HN