Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

781–790 of 943 posts

Re: A 10x Faster TypeScript

#781

Earlier quoted context omitted.

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"

I'm happy to see it to be honest; at this point C# is 25 years old, and since then there's been a lot of innovation and development in programming languages and ecosystems (as well as 10x more software developers, at least - I am guessing at this number). Current-day programming languages, including Go and Typescript, will have had a lot of learnings from C#, including in things like generics and the like.

Go is a step back in key areas: generics, nullability, functional constructs, concurrency. The praise of the latter in particular is egregious. Surely we can do better than having to wire the transfer of data and forking/joining the logical flows manually in 2025? The concept of virtual threading in Go, despite having nice implementation, did not progress much from what we’ve had 10 or even 20 years ago either. It can be more convenient than async/await with hot-started tasks/futures if you predominantly are dealing with sequential code. But for highly concurrent logic working with goroutines is more ceremonious.

Re: A 10x Faster TypeScript

#782

Earlier quoted context omitted.

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"

I don't really get the OOP arguments from Anders. You don't need to do OOP stuff in C# - just write a bunch of static functions if you want. However, I totally get the AOT aspect. Creating a simple cli app meant for wide distribution in .NET isn't great because you either have to ship the runtime or try to use AOT which is very much a step out. I have come to the same conclusion and used Go on some occasions for the…

A “step out” is a single flag passed to “dotnet publish” or set in the project manifest.

Re: A 10x Faster TypeScript

#783

The news for me is Microsoft teams relying on Go. Strange choice to use Go for the compiler instead of C# or F#. Now if they will have problems, they will depend on the Go team at Google to fix them.

> Now if they will have problems, they will depend on the Go team at Google to fix them.

Or collaborate with Go team.

Re: A 10x Faster TypeScript

#784
post #544

Few things are more Microsofty than a team reaching over to a competitor's language instead of using their own and to boot none of the reasons given so far seem credible, good job to the team nonetheless.

I think it's a mature decision, besides, Go is an open source project, calling it "a competitor's language" is a bit derisive. The developers behind Go, Typescript, C#, etc were designing languages well before they were hired by those companies, I don't think they consider their languages a "google" or "microsoft" specific language per se.

Re: A 10x Faster TypeScript

#785

Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?

Nope; 'compiling to javascript' is a relatively trivial operation, just remove the type information. This is what Babel and nowadays NodeJS itself are doing.

What is more important is that tsc does typechecking, which is a static analysis of sorts to ensure code correctness. But this has nothing to do with runtime performance, that's entirely in JS land and in JS transpilers / optimizers.

Re: A 10x Faster TypeScript

#787
post #623

This will be very welcome. I've been working on refactoring very large Typescript files in a very large solution in VS2022. Sometimes it gets into a state where just editing the code or copy/pasting causes it to hang for a few seconds and the fans on my workstation to take off like a jet engine. The typing advantages my team has gotten from migrating our codebase to Typescript has been invaluable, but the performance…

It's the same with formatting and linting, I've heard some people mention long delays caused by eslint / prettier. Biome is faster for formatting, but the eslint plugin ecosystem is still too important for us to switch to Biome for linting as well.

Re: A 10x Faster TypeScript

#788

“Developers rewrite tools from dynamic language to statically compiled one - improves performance by 10x” Also, what’s up with 10x everywhere? Why not 9.5x or 11x?

If you want to be pedantic, the benchmarks they ran showed speedups of 10.4x, 10.1x, 13.5x, 9.5x, 9.1x and 11.0x, for an average of 8.95x.

Re: A 10x Faster TypeScript

#789
post #583

Funny, until now I always thought that TypeScript is JavaScript with some C# vibes https://news.ycombinator.com/item?id=43320086

They're by the same guy, so that tracks. C# did a lot of groundwork for Typescript and other newer language's type systems, like Java did for C#.
Post reply on HN