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

581–590 of 943 posts

Re: A 10x Faster TypeScript

#581

Post by elcritch »

jjice wrote: post #72
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.

I'd love a language that is a GC'd like go, but with the ML inspired type system, and still an imperative language. OCaml seems to be the closest thing to Rust in that regard, but it's not imperative.

Nim is pretty close to that for me. It’s more pascal-ish inherited but has a sophisticated type system including case types similar to ML sum types and compile time.

Re: A 10x Faster TypeScript

#582

Post by crabmusket »

singularity2001 wrote: post #562

So now tsc is a binary, browsers can efficiently bundle it and compile index.ts on the fly ... please?

> browsers can efficiently bundle it

That's really not what's stopping TS being built in to browsers. Have a look at the discussions around the types-as-comments proposal https://tc39.es/proposal-type-annotations/

Re: A 10x Faster TypeScript

#584

Post by _ink_ »

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…

Does Deno benefit from that?

Re: A 10x Faster TypeScript

#585

Post by auxiliarymoose »

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?

This was touched on in the video a little bit—essentially, the TypeScript codebase has a lot of polymorphic function calls, and so is generally hard to JIT optimize. JS to Go therefore yielded a direct ~3.5x improvement.

The rest of the 10x comes from multi-threading, which wasn't possible to do in a simple way in the JS compiler (efficient multithreading while writing idiomatic code is hard in JS).

JavaScript is very fast for single-threaded programs with monomorphic functions, but in the TypeScript compiler's case, the polymorphic functions and opportunity for parallelization mean that Go is substantially faster while keeping the same overall program structure.

Re: A 10x Faster TypeScript

#587

Post by gauge_field »

dimgl wrote: post #461
J_Shelby_J wrote: post #410

Earlier quoted context omitted.

Is this visceral reaction in the room with us now? Edit: I have reached the bottom of the thread and still have not seen this visceral reaction mentioned by the OP.

https://github.com/microsoft/typescript-go/discussions/411 There's more reactions here. I think devs have lost the plot, tbh.

I am not sure if we see the same thread. There is one reaction from "Rust" dev (who seems have a very new account on github) on why not rust. Most of the others seem to be from C# side. The pattern also seems to be the same on reddit thread. There is one post about why not rust, equally (or more depending how you weigh) is how other people react to this news.

What is weird is how much people talk about how other people react. Modern social media is weird

Re: A 10x Faster TypeScript

#588

Post by wiseowise »

ragnese wrote: post #291
rvz wrote: post #123

Earlier quoted context omitted.

There you go. All the bootcamp cargo culting crew have pumped these lies such as "the language doesn't matter" or "learn coding in 1 week for a SWE job with JS / TS" and it has caused the increase in low quality software and with several developers asking how to improve or add "performance" optimizations as such. What we have just seen is that the TS team has admitted that a limit has been reached and *almost always*…

Can you imagine the progress we could've made by now if people just tried to use the right tool for the job instead of trying to make the wrong tool good enough? All the time spent trying to optimize JITs for JavaScript engines, or alternative Python implementations (e.g., PyPy), and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications. Ugh...

> and fruitless efforts like trying to get JVMs to start fast enough for use in cloud "lambda function" applications

This is how we got Graal, why would you call it "fruitless effort"?

Re: A 10x Faster TypeScript

#589

Post by muglug »

aylmao wrote: post #558
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.

This is awesome. Thanks to you and all the TypeScript team for the work they put on this project! Also, nice to see you here, engaging with the community. Porting to Go was the right decision, but part of me would've liked to see a different approach to solve the performance issue. Here I'm not thinking about the practicality, but simply about how cool it would've been if performance had instead been improved via: -…

Not Daniel, but I've ported a typechecker from PHP to Rust (with some functional changes) and also tried working with the official Hack OCaml-based typechecker (a precursor to Flow).

Rust and OCaml are _maybe_ prettier to look at, but for the average TypeScript developer Go is a much more understandable target IMO.

Lifetimes and ownership are not trivial topics to grasp, and they add overhead (as discussed here: https://github.com/microsoft/typescript-go/discussions/411) that not all contributors might grasp immediately.

Re: A 10x Faster TypeScript

#590

Post by rat9988 »

nipah wrote: post #510
rat9988 wrote: post #282

Earlier quoted context omitted.

I didn't say it was very performance critical, go and c# are both good enough for us in this regard. The problem is that, when evaluating the whole thing, they decided against c#, that is problematic here.

But they not stated it is of C#'s performance, so I don't think this is THAT problematic. But I agree that it would be fine to see them dogfeeding on their language for such a massive project, and a project that is even related to TypeScript (as it inspired it in some features), it is a shame they don't do it, but it is also the case for many of their projects (like, they are even pushing react native for apps nowada…

> But they not stated it is of C#'s performance

But I just said my point is not about performance at all! It is about the whole package. Performance of c# and go are both enough for my usecase, same for java and c obviously. They just told us that they don't think the whole package makes sense, and disowned the AOT compilation.

Post reply on HN