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

571–580 of 943 posts

Re: A 10x Faster TypeScript

#571

Post by 9rx »

nipah wrote: post #534
9rx wrote: post #379

Earlier quoted context omitted.

It was stated from the angle of wanting to ship software sometime this century. But there is probably some truth in what you say as well. Footguns are no doubt refreshing after being engrossed in Typescript (and C#) for decades. At some point you start to notice that your tests end up covering all the same cases as your advanced types, and you begin question why you are putting in so much work repeating yourself, whi…

> At some point you start to notice that your tests end up covering all the same cases as your advanced types I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests, they either tell some objective truths about your code in compile time (thus reducing the natural need for specific tests) or your type system is simply useless. Either way, I don't think the "industry…

> I don't think this is fair [at all], you use the types precisely to not need to be so overreliable on tests

At the extreme end of the spectrum that starts to become true. But the languages that fill that space are also unusable beyond very narrow tasks. This truth is not particularly relevant to what is seen in practice.

In the realm of languages people actually use on a normal basis, with their half-assed type systems, a few more advanced concepts sprinkled in here and there really don't do anything to reduce the need for testing as you still have to test around all the many other holes in the type system, which ends up incidentally covering those other cases as well.

In practice, the primary benefit of the type system in these real-world languages is as it relates to things like refactoring. That is incredibly powerful and not overlapped by tests. However, the returns are diminishing. As you get into increasingly advanced type concepts, there is less need/ability to refactor on those touch points.

Most seem to agree that a complete type system is way too much (especially for general purpose programming), and no type system is too little; that a half-assed type system is the right balance. However, exactly how much half-assery is the right amount of half-assery is where the debate begins. I posit that those who go in deep with thinking less half-assery is the way eventually come to appreciate more half-assery.

> I don't think the "industry" is a person

Nobody does.

Re: A 10x Faster TypeScript

#572

Post by jchw »

merb wrote: post #541
jchw wrote: post #54

Earlier quoted context omitted.

Honestly, the choice seems fine to me: the vast majority of users are not compiling huge TypeScript projects in the browser. If you're using Vite/ESBuild, you're already using a Go-based JS toolchain, and last I checked Vite was pretty darn popular. I don't suspect there will be a huge burden for things like playground; given the general performance uplift that the Go tsc implementation already gets, it may in fact b…

I‘m pretty sure that a lot of vite users with hot reload will run tsc inside the browser (tanstack, react-router)

I am not a Vite expert, however, when running Vite in dev mode, I can see two things:

- There is an esbuild process running in the background.

- If I look at the JavaScript returned to the browser, it is transpiled without any types present.

So even though the URLs in Vite dev mode look like they're pointing to "raw" TypeScript files, they're actually transpiled JavaScript, just not bundled.

I could be incorrect, of course, but it sure seems to me like Vite is using ESBuild on the Node.JS side and not tsc on the web browser side.

Re: A 10x Faster TypeScript

#573

Post by smarx007 »

kevlened wrote: post #372

For previous attempts at a faster tsc, but in rust, see: 1. https://github.com/dudykr/stc - Abandoned ( https://github.com/swc-project/swc/issues/571#issuecomment-1... ) 2. https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.

I think Deno and Bun are the two successful attempts at a faster tsc :)

Re: A 10x Faster TypeScript

#575

Post by keturakis »

smarx007 wrote: post #573
kevlened wrote: post #372

For previous attempts at a faster tsc, but in rust, see: 1. https://github.com/dudykr/stc - Abandoned ( https://github.com/swc-project/swc/issues/571#issuecomment-1... ) 2. https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.

I think Deno and Bun are the two successful attempts at a faster tsc :)

Both Deno and Bun still use current tsc for type checking

Re: A 10x Faster TypeScript

#576

Post by steveklabnik »

jchw wrote: post #564
steveklabnik wrote: post #497

Earlier quoted context omitted.

> On the other hand, though, in practice, I've wound up using Go in production quite a lot, and these bugs are excessively rare. I both want to agree with this, but also point to things like https://www.uber.com/en-CA/blog/data-race-patterns-in-go/ , which found a bunch of bugs. They don't really contextualize it in terms of other kinds of bugs, so it's really hard to say from just this how rare they actually are. On…

The Uber page does a pretty good job of summing it up. The only thing I'd add is that there has been a little bit of effort to reduce footguns since they've posted this article; as one example, the issue with accidentally capturing range for variables is now fixed in the language[1]. On top of having a built-in (runtime) race detector since 1.1 and runtime concurrent map access detection since 1.6, Go is also adding…

Ah, that's great info, thank you :)

Re: A 10x Faster TypeScript

#577

Post by chamomeal »

pseudopersonal wrote: post #22
gr__or wrote: post #13

Earlier quoted context omitted.

I can think of a DOOM that WILL run faster… https://youtu.be/0mCsluv5FXA

Ah thanks! I didn't realize there was a Doom running on the TS type system. I stand corrected

lol it just “released” recently. Like in the last couple of weeks. It shook the typescript world.

It’s been a crazy couple of weeks for TS!!

Re: A 10x Faster TypeScript

#578

Post by nicoburns »

zozbot234 wrote: post #438
airforce1 wrote: post #433

Earlier quoted context omitted.

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing. I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been ver…

I think the Wasm backends for both Golang and LLVM have yet to support the Wasm GC extension, which would likely be needed for anything like real parity with JS. The present approach is effectively including a full GC implementation alongside your actual Golang code and running that within the Wasm linear memory array, which is not a very sensible approach.

> the Wasm GC extension, which would likely be needed for anything like real parity with JS

Well, for languages that use a GC. People who are writing WASM that exceeds JS in speed are typically doing it in Rust or C++.

Re: A 10x Faster TypeScript

#579

Post by crabmusket »

tomatofrank wrote: post #477

Very pumped to see how this improves the experience in VSCode. I've been revisiting my editing setup over the last 6 months and to my surprise I've time traveled back to 2012 and am once again really enjoying Sublime Text. It's still by far the most performant editor out there, on account of the custom UI toolkit and all the incredibly fast indexing/search/editing engines (everything's native). Not sure how this anno…

> Not sure how this announcement impacts VSCode's UI being powered by Electron

It has no bearing on this at all.

Re: A 10x Faster TypeScript

#580

Post by madjam002 »

smarx007 wrote: post #573
kevlened wrote: post #372

For previous attempts at a faster tsc, but in rust, see: 1. https://github.com/dudykr/stc - Abandoned ( https://github.com/swc-project/swc/issues/571#issuecomment-1... ) 2. https://github.com/kaleidawave/ezno - In active development. Does not have the goal of 1:1 parity to tsc.

I think Deno and Bun are the two successful attempts at a faster tsc :)

They just strip types and don’t do any type checking
Post reply on HN