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

241–250 of 943 posts

Re: A 10x Faster TypeScript

#241

Post by libria »

ChocolateGod wrote: post #47
dimitropoulos wrote: post #2

yes, this will definitely vastly increase the Doom fps, haha (I’m the guy that did that project). But I think there’s a lot more to it than that. tl;dr — Rust would be great for a rewrite, but Go makes way more sense for a port. After the dust settles, I hope people focus on the outcomes, not the language choice. I was very surprised to see that the TypeScript team didn’t choose Rust, not just because it seemed like…

imho Go is a far easier language to learn than Rust, so it lowers the barrier to entry for new contributors.

Is learning a language even a thing anymore with $Internal_or_external_LLM_helper plugin available for every IDE? I haven't found syntax lookups to be that much a concern anymore and any boneheaded LLM suggestions are trivial to detect/fix.

Re: A 10x Faster TypeScript

#242

Post by SkiFire13 »

sapiogram wrote: post #229
ninetyninenine wrote: post #221

Earlier quoted context omitted.

I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.

Rust loses a lot of its nice properties without borrow checking and lifetimes, though. For example, resources no longer get cleaned up automatically, and the compiler no longer protects you against data races. Which in turn makes the entire language memory unsafe.

I believe OP meant to give it a GC like in Go, while keeping other features from Rust from enums/match/generics/traits/etc etc.

This should prevent most of the memory safety issues, though data races could still be tricky (e.g. Go is memory unsafe due to data races)

Re: A 10x Faster TypeScript

#243

Post by spankalee »

RyanCavanaugh wrote: post #83
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

Our best estimate for how much faster the Go code is (in this situation) than the equivalent TS is ~3.5x In a situation like a game engine I think 1.5x is reasonable, but TS has a huge amount of polymorphic data reading that defeats a lot of the optimizations in JS engines that get you to monomorphic property access speeds. If JS engines were better at monomorphizing access to common subtypes across different map sha…

> If JS engines were better at monomorphizing access to common subtypes across different map shapes maybe it'd be closer, but no engine has implemented that or seems to have much appetite for doing so.

I really wish JS VMs would invest in this. The DOM is full of large inheritance hierarchies, with lots of subtypes, so a lot of DOM code is megamorphic. You can do tricks like tearing off methods from Element to use as functions, instead of virtual methods as usual, but that quite a pain.

Re: A 10x Faster TypeScript

#244

Post by noelwelsh »

ninetyninenine wrote: post #221
Starlord2048 wrote: post #211

[flagged]

I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.

O'Caml is similar, now that it has multicore. Scala is also similar, though the native code side (https://scala-native.org/en/stable/) is not nearly as well developed as the JVM side.

Re: A 10x Faster TypeScript

#245

Post by steve_adams_86 »

wesbos wrote: post #57
mcintyre1994 wrote: post #38

Earlier quoted context omitted.

Ah that'll be the thing Wes was under NDA about and teasing how excited he was on twitter last week!

haha yep, everyone thought it was related to Vite. which I guess I kinda is?

I was hoping for something related to vacuums, but this is great too

Re: A 10x Faster TypeScript

#246

Post by [deleted] »

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…

[deleted]

Re: A 10x Faster TypeScript

#247

Post by pjmlp »

cheepin wrote: post #171
pjmlp wrote: post #44

Earlier quoted context omitted.

Personally, Rust only makes sense in scenarios that automatic memory management of any kind is either unwanted, or it is a quixotic battle making the target group think otherwise. OS kernels, firmware, GPGPU,.... If it is the ML inspired type system, there are plenty of options among compiled managed languages, true Go isn't really on that camp, but whatever.

Rust memory management is automatic. Object destructors run when the object exits scope without needing explicit management by the programmer

More like compiler assisted management, with compiler errors when the developer doesn't follow the teacher.

Re: A 10x Faster TypeScript

#248

Post by vessenes »

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.

I’m sure Microsoft’s strategy department would disagree with you. As a c# devotee - I get that you’re upset. And you may want to update your priors on where c# sits in Microsoft’s current world. But I think it’s a mistake to imagine this isn’t a well reasoned decision.

Re: A 10x Faster TypeScript

#249

Post by rvz »

Starlord2048 wrote: post #211

[flagged]

> When a language team abandons self-hosting (TS in TS) for raw performance (Go), it signals we've hit fundamental limits in JS/TS for systems programming.

I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant.

I don't know why one would choose JS or TS for "systems programming", but I'm assuming you're talking about user-space programs.

But really, those who know the difference between a compiled language and a VM-based language know the obvious fundamental performance limitations of developer tools written in VM-based languages like JS or TS and would avoid them as they are not designed for this use case.

Re: A 10x Faster TypeScript

#250

Post by AshleysBrain »

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…

I'd say that our JS game engine codebase is generally idiomatic, maintainable JS. We don't really do anything too esoteric to get maximum performance - modern JS engines are phenomenal at optimizing idiomatic code. The best JS performance advice is to basically treat it like a statically typed language (no dynamically-shaped objects etc) - and TS takes care of that for you. I suppose a compiler is a very different use case and may do things like lean on the GC more, but modern JS GCs are also amazing.

Basically I'd be interested to know what the bottlenecks in tsc are, whether there's much low-hanging fruit, and if not why not.

Post reply on HN