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

191–200 of 943 posts

Re: A 10x Faster TypeScript

#191

Post by tialaramex »

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…

A tiny thing that's not relevant to this particular piece of work but is worth having in background when thinking about Go is that while Go would like Python typically be described as "memory safe" unlike Java (or more remarkably, Rust) it is very possible for naive programmers to cause undefined behaviour in this language without realising it.

Specifically if you race any non-trivial Go object (say, a hash table, or a string) then that's immediately UB. Internally what's happening is that these objects have internal consistency rules which you can easily break this way and they're not protected against that because the trivial way to do so is expensive. Writing a Go data race isn't as trivial as writing a use-after-free in C++ but it's not actually difficult to do by mistake.

In single threaded software this is no caveat at all, but most large software these days does have some threading involved.

Re: A 10x Faster TypeScript

#192

Post by hombre_fatal »

surajrmal wrote: post #178
Etheryte wrote: post #62

Earlier quoted context omitted.

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.

Tell that to the deno project.

Deno compiles TS to JS before execution.

Re: A 10x Faster TypeScript

#193

Post by zem »

0xcb0 wrote: post #110

After years of PHP, I came to typescript nearly 4 years ago (for web front and backend development). All I can say is that I really enjoy using this programming language. The type system is just about enough to be helpful, and not too much to be in your way. Compiling the codebase is quite fast, compared to other languages. With a 10x, it will be so much fun to code. Never been a big fan of MS, but must say that type…

microsoft has historically been great at programming languages. qbasic, visual basic, c#, and f# are all excellent.

Re: A 10x Faster TypeScript

#194

Post by alabastervlog »

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... .

From the title, my initial assumption was someone wrote a compiler & runtime for typescript that doesn't target javascript, which was very exciting. And I do work with typescript.

Re: A 10x Faster TypeScript

#195

Post by frou_dh »

rickette wrote: post #122
ChocolateGod wrote: post #47

Earlier quoted context omitted.

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

Some big projects have so many people trying to do PRs that it's actually a bit of a hassle to deal with them all. So I don't think maximising the number of contributors should necessarily be one of the top goals for projects that are already big or have guaranteed relevance.

Re: A 10x Faster TypeScript

#196

Post by dec0dedab0de »

kaoD wrote: post #10
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…

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…

“faster typescript” would also be a valid way to say the typescript compiler found a way to automatically write more performant javascript.

Just like if you said faster C++ that could mean the compiler runs faster, or the resulting machine code runs faster.

Just because the compile target is another human readable language doesn’t mean it ceases to be a typescript program.

I didn’t think this particular example was very ambiguous because a general 10x speed up in the resulting JS would be insane, and I have used typescript enough to wish the compiler was faster. Though if we’re being pedantic, which I enjoy doing sometimes, I would say it is ambiguous.

Re: A 10x Faster TypeScript

#199

Post by surajrmal »

pjmlp wrote: post #44
jjice wrote: post #31

Earlier quoted context omitted.

If I recall in an article from a while back, the idea was originally rust, but the current compiler design had lots of references shared references that would make the port to rust a lot of work.

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.

Or possibly you want to use a language you're familiar with in adjacent spaces (eg tools) or you want to tackle concurrency bugs more directly. There is more to rust than it's

Re: A 10x Faster TypeScript

#200

Post by whatthemick »

neonsunset wrote: post #154
duckerude wrote: post #119

Earlier quoted context omitted.

Anders Hejlsberg explains here: https://youtu.be/10qowKUW82U?t=1154 . TL;DW: - C# is bytecode-first, Go targets native code. While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it. Go also has somewhat better control over data layout. They wanted to get as low-level as possible while still having garbage collection. - This is meant to be something of a 1:1 port rat…

This is shockingly out-of-date statement by Anders. I'm not sure what's going on, I guess he's just not involved with the runtime side of .NET at all to actually know where the capability sits circa 2024/2025. But really, it's a terrible situation to be in. Especially just how worse langdev UX in Go is compared to C#, F# or Rust. No one would've batted an eye if either of those was used.

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