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

251–260 of 943 posts

Re: A 10x Faster TypeScript

#251

Post by pjmlp »

neonsunset wrote: post #206
whatthemick wrote: post #200

Earlier quoted context omitted.

Isn't the AOT story for F# pretty meh? AOT + System.Text.Json requires source generation as best I can tell, which F# doesn't support yet (to my knowledge).

In complex projects like this, Go requires manual scripting and build-time code generation. Arguably, writing a small shim project in C# is much easier. You don't exactly do a lot of JSON serialization in a compiler either way. Other than that - F# "just works" and does not require anything extra. It is just IL after all. NativeAOT story itself is also interesting - I noted it in a sibling comment but .NET has much b…

I already hinted on BlueSky that they shouldn't wonder why .NET has adoption problems outside the traditional Windows ecosystem, when decisions like these are taken.

Re: A 10x Faster TypeScript

#253

Post by pjmlp »

reactordev wrote: post #188
pjmlp wrote: post #149

Earlier quoted context omitted.

Native AOT exists, and C# has many C++ like capabilities, so not at all.

It exists but isn’t the same as a natively compiled binary. A lot gets packed into an AOT binary for it to work. Longer startup times, more memory, etc.

Just like Go, there is no magic here.

Where do you think Go gets those chubby static linked executables from?

That people have to apply UPX on top.

Re: A 10x Faster TypeScript

#254

Post by austin-cheney »

pjc50 wrote: post #14
bcherny wrote: post #5

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.

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.

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.

Re: A 10x Faster TypeScript

#255

Post by mohsen1 »

polskibus wrote: post #216
fixprix wrote: post #160

Earlier quoted context omitted.

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…

A missed opportunity to improve c# by dogfooding it with TS compiler rewrite.

C# is too old to change that drastically, just like me

Re: A 10x Faster TypeScript

#256

Post by neonsunset »

pjmlp wrote: post #251
neonsunset wrote: post #206

Earlier quoted context omitted.

In complex projects like this, Go requires manual scripting and build-time code generation. Arguably, writing a small shim project in C# is much easier. You don't exactly do a lot of JSON serialization in a compiler either way. Other than that - F# "just works" and does not require anything extra. It is just IL after all. NativeAOT story itself is also interesting - I noted it in a sibling comment but .NET has much b…

I already hinted on BlueSky that they shouldn't wonder why .NET has adoption problems outside the traditional Windows ecosystem, when decisions like these are taken.

The nightmare of Midori never ends. And especially right as the platform, from the technical standpoint, is getting really good(tm).

Re: A 10x Faster TypeScript

#258

Post by wrs »

sapiogram wrote: post #239
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 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.

It’s a little more nuanced though — I doubt the audio processing in Discord is written in JavaScript. (But I haven’t looked!)

Re: A 10x Faster TypeScript

#259

Post by nindalf »

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.

That would explain a lot.

Re: A 10x Faster TypeScript

#260

Post by madeofpalk »

Starlord2048 wrote: post #211

[flagged]

> it signals we've hit fundamental limits in JS/TS for systems programming

Really is this a surprise to anyone? I don't think anyone thinks JS is suitable for 'systems programming'.

Javascript is the language we have for the browser - there's no value in debating it's merits when it's the only option. Javascript on the server has only ever accrued benefits from being the same language as the browser.

Post reply on HN