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

521–530 of 943 posts

Re: A 10x Faster TypeScript

#521

Post by rafram »

gwbas1c wrote: post #350
DanRosenwasser wrote: post #3

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.

Thanks for answering questions. One thing I'm curious about: What about updating the original Typescript-based compiler to target WASM and/or native code, without needing to run in a Javascript VM? Was that considered? What would (at a high level) the obstacles be to achieving similar performance to Golang? Edit: Clarified to show that I indicate updating the original compiler.

It's unlikely that you would get much performance benefit from AOT compiling a TypeScript codebase. (At least not with a ton of manual optimization of the native code, and if you're going to do that, why not just rewrite in a native-first language?)

JavaScript, like other dynamic languages, runs well with a JIT because the runtime can optimize for hotspots and common patterns (e.g. this method's first argument is generally an object with this shape, so write a fast path for that case). In theory you could write an AOT compiler for TypeScript that made some of those inferences at compile time based on type definitions, but

(a) nobody's done that

(b) it still wouldn't be as fast as native, or much faster than JIT

(c) it would be limited - any optimizations would die as soon as you used an inherently dynamic method like JSON.parse()

Re: A 10x Faster TypeScript

#522

Post by crabmusket »

darthrupert wrote: post #395

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?

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?

Re: A 10x Faster TypeScript

#523

Post by almosthere »

electroly wrote: post #143
DanRosenwasser wrote: post #59

Earlier quoted context omitted.

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…

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, pretend they decided they decided to write it in Java and ask if you think Node/React/Typescript developers WANT to install Java.

Re: A 10x Faster TypeScript

#524

Post by johnisgood »

christianqchung wrote: post #424
mannykoum wrote: post #273

Earlier quoted context omitted.

Sorry for being pedantic but they are using an en dash (–) not an em dash (—) which is a little strange because the latter is usually the one meant for adding information in secondary sentences—like commas and and parentheses. In addition, in most styles, you're not supposed to add spaces around it. So, I don't think the comment is AI-generated for this reason.

You're right, oops. I agree with your reasoning (comment still gives off slop vibes but that's unprovable). But the parent has been flagged, so I'm not sure if that means admins/dang has agreed with me or if it was flagged for another reason.

I think anyone can flag a comment, and if enough people flag a comment, it will become flagged.

Re: A 10x Faster TypeScript

#526

Post by mike_hearn »

neonsunset wrote: post #520
mike_hearn wrote: post #518

Earlier quoted context omitted.

I wonder if there's just some cultural / generational stuff happening there too. The fact that the TS compiler is all about compiling a highly complex OOP/functional hybrid language yet is said to use neither objects nor FP seems rather telling. Hejlsberg is famous for designing object oriented languages (Delphi, C#) but the Delphi compiler itself was written largely in assembly, and the C# compiler was for a very lo…

> Roslyn It was introduced back then with .NET Framework 4.6 (C# 6) - a loong time ago (July 2015). The OSS .NET has started with Roslyn from the very beginning. > And the Java AOT compiler (native image) is not only fully written in Java itself, everything from optimizations to code generation, but even the embedded runtime is written in Java too. NativeAOT uses the same architecture. There is no C++ besides GC and…

Ah C# 6 not .NET 6, thanks for the correction. Cool to hear that the NativeAOT stuff follows the same path.

Re: A 10x Faster TypeScript

#527

Post by moogly »

jay_kyburz wrote: post #480
uticus wrote: post #453

Earlier quoted context omitted.

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course). So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages. If Ford made a car and powered it with a Chevy e…

It's a bad look for both C# and TypeScript. Anybody starting a new code base now would be looking for ways to avoid both and jump right to Go.

If they're writing (actually porting) a _compiler_, perhaps.

Re: A 10x Faster TypeScript

#528

Post by IshKebab »

electroly wrote: post #176
vessenes wrote: post #164

Earlier quoted context omitted.

It’s a political anti-benefit in most of the open-source world. And C# is not considered a high quality runtime once you leave Windows.

This is Anders Hejlsberg , the creator of C# , working on a politically important project at Microsoft . That's what I mean by political benefit. The larger open source world doesn't matter for this decision which is why this is a simple announcement of an internal Microsoft decision rather than an invitation for comments ahead of time.

> The larger open source world doesn't matter for this decision

It obviously does because the larger open source world are huge users of Typescript. This isn't some business-only Excel / PowerBI type product.

To put it another way, I think a lot of people would get quite pissed if tsc was going to be rewritten in C# because of the obvious headaches that's going to cause to users. Go is pretty much the perfect option from a user's point of view - it generates self-contained statically linked binaries.

Re: A 10x Faster TypeScript

#529

Post by nipah »

9rx wrote: post #286
homebrewer wrote: post #151

Earlier quoted context omitted.

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

> 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?"

This is not "the main reason", lol, it was never stated as such. The type system could be way more powerful and, having the same general features they would probably had still picked it up.

Re: A 10x Faster TypeScript

#530

Post by melbourne_mat »

zoogeny wrote: post #230

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

I think it's smart to start with a high level language which should reduce development time, prove the worth of the application, then switch to a lower level language later.

What was that saying again? Premature optimisation is the root of all evil

Post reply on HN