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

321–330 of 943 posts

Re: A 10x Faster TypeScript

#321

Post by immibis »

do_not_redeem wrote: post #79
AshleysBrain wrote: post #64

Earlier quoted context omitted.

Well-optimized JavaScript can get to within about 1.5x the performance of C++ - something we have experience with having developed a full game engine in JavaScript [1]. Why is the TypeScript team moving to an entirely different technology instead of working on optimizing the existing TS/JS codebase? [1] https://www.construct.net/en

Well-optimized JavaScript can, if you jump through hoops like avoiding object creation and storing your data in `Uint8Array`s. But idiomatic, maintainable JS simply can't (except in microbenchmarks where allocations and memory layout aren't yet concerns). In a game engine, you probably aren't recreating every game object from frame to frame. But in a compiler, you're creating new objects for every file you parse. Tha…

In other words you write asm.js, which is a textual form of WebAssembly that is also valid Javascript, and if your browser has an asm.js JIT compiler - which it doesn't because it was replaced by WebAssembly.

Re: A 10x Faster TypeScript

#322

Post by ackfoobar »

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.

Will we still have compiler plugins? What will this mean for projects like ts-patch?

Re: A 10x Faster TypeScript

#323

Post by cjbgkagh »

tobyhinloopen wrote: post #141
pizlonator wrote: post #115

Misleading title. TypeScript isn't getting 10x faster. The compiler is 10x faster.

TS is nothing but a compiler

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.

Re: A 10x Faster TypeScript

#324

Post by vips7L »

fixprix wrote: post #160
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…

Anders answers that question here - https://www.youtube.com/watch?v=10qowKUW82U&t=1154s Transcript: "But I will say that I think Go definitely is much more low-level. I'd say it's 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 contrast, C# is sort of bytecode-first, if you will. There are some ahead…

An unpopular pick that is probably more low level than Go but also still has a GC: D. Understandable why you wouldn't pick D though. Its ecosystem is extremely small.

Re: A 10x Faster TypeScript

#325

Post by goatlover »

zamadatix wrote: post #295
wrs wrote: post #219

Earlier quoted context omitted.

Not really in the case of TypeScript, because (with very small exceptions) when you “compile” TypeScript you are literally just removing the TypeScript , leaving plain JavaScript. It’s just type annotations; it doesn’t describe any runtime behavior at all.

That depends on both the target and the typescript features you use. In many cases, even when down leveling isn't involved, transpiled code can result in more than just stripping type info (particularly common in classes or things with helper functions). There's also nothing stopping a typescript compiler from optimizing transpiled (or directly compiled) code like any other compiler would, though the default typescri…

But the end result is still a JS runtime.

Re: A 10x Faster TypeScript

#326

Post by zozbot234 »

vessenes wrote: post #163
pjmlp wrote: post #84

Earlier quoted context omitted.

Thanks, but it really doesn't clarify why a team with roots on the .NET ecosystem decided C#/Native AOT isn't fit for purpose.

Pure speculation, but C# is not nearly the first class citizen that go binaries are when you look at all possible deployment targets. The “new” Microsoft likely has some built-in bias against “embrace and extend” architectural and business decisions for developers. Overall this doesn’t seem like a hard choice to me. Cue rust devotees in 3, 2, ..

> Cue rust devotees in 3, 2, ..

If you are a rust devotee, you can use https://github.com/FractalFir/rustc_codegen_clr to compile your rust code to the same .NET runtime as C#. The project is still in the works but support is said to be about 95% complete.

Re: A 10x Faster TypeScript

#327

Post by zamadatix »

goatlover wrote: post #325
zamadatix wrote: post #295

Earlier quoted context omitted.

That depends on both the target and the typescript features you use. In many cases, even when down leveling isn't involved, transpiled code can result in more than just stripping type info (particularly common in classes or things with helper functions). There's also nothing stopping a typescript compiler from optimizing transpiled (or directly compiled) code like any other compiler would, though the default typescri…

But the end result is still a JS runtime.

Agreed, at least usually right now (it doesn't have to be forever, which would probably be the most realistic way for TypeScript to make meaningful runtime gains). That does not preclude the possibility of producing more optimal JavaScript code for the runtime to consume. I give a couple examples of that in the other comments.

Re: A 10x Faster TypeScript

#328

Post by homebrewer »

DrBenCarson wrote: post #288

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?

> 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

Re: A 10x Faster TypeScript

#329

Post by harrall »

christianqchung wrote: post #238
Starlord2048 wrote: post #211

[flagged]

This is not accusatory, but do you write your comments with AI? I checked your profile and someone else had the same question a few days ago. It's the persistent structure of "it isn't X – it's Y" with the em dash (– not -) that makes me wonder this. Nothing to add to your comment otherwise, sorry.

Two hyphens (-) make a em dash (—) on Apple devices and many word processors.

In the pre-Unicode days, people would use two hyphens (--) to simulate em dashes.

Re: A 10x Faster TypeScript

#330

Post by DrammBA »

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.
Post reply on HN