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

121–130 of 943 posts

Re: A 10x Faster TypeScript

#121

Post by ramon156 »

dagw wrote: post #76
pier25 wrote: post #53

Earlier quoted context omitted.

Anders explain why Go in this podcast: https://youtu.be/ZlGza4oIleY?t=1005

TL:DR; - Native executable support on all major platforms - He doesn't seen to believe that AOT compiled C# can give the best possible performance on all major platforms - Good control of the layout of data structures - Had to have garbage collection - Great concurrency support - Simple, easy to approach, and great tooling

So wild that most of these points were something C# was supposed to be good at, and they all boil down to "its just not as good in C# as in Go"

Re: A 10x Faster TypeScript

#122

Post by rickette »

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.

Which is a massive pro for any open source project

Re: A 10x Faster TypeScript

#123

Post by rvz »

ragnese wrote: post #80

But, I was told that programming language choice doesn't matter and that I can write slow/bad code in any language... /s

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* the solution is either porting it to a compiled language or relying on scaling with new computers with new processors in accordance to Moore's Law to get performance for free.

Now the bootcampers are rediscovering why we need "static typing" and why a "compiled language" is more performant than a VM-based language.

Re: A 10x Faster TypeScript

#124

Post by ethan_smith »

Wow, this is huge! A 10x speedup is going to be game-changing for large TypeScript codebases like ours. I've been waiting for something like this - my team's project takes forever to typecheck on CI and slows down our IDE.

Hopefully this would also reduce the memory footprint because my VS Code intelisense keeps crashing unless I give it like 70% of my RAM, its probably because of our fairly large graphql.ts file which contains auto-generated grapqhl types.

Re: A 10x Faster TypeScript

#125

Post by maxloh »

lytedev wrote: post #100
spankalee wrote: post #88

Earlier quoted context omitted.

Hey Daniel. I write a lot of tools that depend on the TypeScript compiler API, and they run in a lot of a lot of JS environments including Node and the browser. The current CJS codebase is even a little tricky to load into standard JS module supporting environments like browsers, so I've been _really_ looking forward to what Jake and others have said will be an upcoming standard modules based version. Is that still h…

Reading the article, it looks like they are writing go, so will probably be distributing go binaries.

Maybe they'll also be distributed in WASM too, which is easier to be integrated with JavaScript codebases.

Re: A 10x Faster TypeScript

#127

Post by wendyshu »

Etheryte wrote: post #62
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…

I don't think it's misleading at all, because you can't run Typescript. Typescript is either compiled, transpiled or stripped down into another language and that's what gets run in the end.

Sure you can run Typescript. It's a programming language, someone could always write an interpreter for it.

Re: A 10x Faster TypeScript

#128

Post by dcre »

grantwu wrote: post #50

> By far the most important aspect is that we need to keep the new codebase as compatible as possible, both in terms of semantics and in terms of code structure. We expect to maintain both codebases for quite some time going forward. Languages that allow for a structurally similar codebase offer a significant boon for anyone making code changes because we can easily port changes between the two codebases. In contrast…

In the embedded video they show some of the code side by side and it is just a ton of if statements.

https://youtu.be/pNlq-EVld70?si=UaFDVwhwyQZqkZrW&t=323

Re: A 10x Faster TypeScript

#129

Post by felixrieseberg »

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.

Daniel, congrats! I'm _so_ excited about everything y'all have achieved in the last few years.

Re: A 10x Faster TypeScript

#130

Post by fastball »

pseudopersonal wrote: post #60
kaoD wrote: post #10

Earlier quoted context omitted.

To clarify why it's actually not that ambiguous: TS is not (and does not have) a runtime at all. Even TS-first runtimes like Deno are (1) not TS but its own thing and most importantly (2) just JS engines with a frontend layer that treats TS as a first-class citizen (in Deno's case, V8). It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further (e.g. by proving that a functi…

Thanks for the clarification. For those of us who don't use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn't know if it's about a compiler or a runtime. What if they announced a bun competitor? https://betterstack.com/community/guides/scaling-nodejs/node... .

Those are javascript runtimes, not TypeScript runtimes. The point stands.

If you don't know enough about TypeScript to understand that TypeScript is not a runtime, I'm not sure why you would care about TypeScript being faster (in either case).

Post reply on HN