Live data from Hacker News

A 10x Faster TypeScript

devblogs.microsoft.com

141–150 of 943 posts

Re: A 10x Faster TypeScript

#142
post #18

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…

> I was very surprised to see that the TypeScript team didn’t choose Rust Typescript is a Microsoft project, right? I’m surprised they didn’t choose C#.

he went into the C# question in more detail this interview: https://youtu.be/10qowKUW82U?t=1154s

Re: A 10x Faster TypeScript

#143

Earlier quoted context omitted.

Like others I'm curious about the choice of technology here. I see you went with Go, which is great! I know Go is fast! But its also a more 'primitive' language (for lack of a better way of putting it) with no frills. Why not something like Rust? Most of the JS ecosystem that is moving toward faster tools seem to be going straight to Rust (Rolldown, rspack (the webpack successor) SWC, OXC, Lightning CSS / Parcel etc)…

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I'll post the response below. https://github.com/microsoft/typescript-go/discussions/411 . ____ Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a nativ…

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C#, given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?"

C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed.

C# has all that stuff that the FAQ mentions about Go while also having an obvious political benefit. I'd hope the creator of said language who also made the decision not to use it would have an interesting opinion on the topic! I really hope we find out the real story.

As a C# developer I don't want to be offended but, like, I thought we were friends? What did we do wrong???

Re: A 10x Faster TypeScript

#144
post #16

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.

Why not AOT compiled C#, given the team's historical background?

I'm not involved in the decisions, but don't C# applications have a higher startup time and memory usage? These are important considerations for a compiler like this that needs to start up and run fast in e.g. new CI/CD boxes.

For a daemon like an LSP I reckon C# would've worked.

Re: A 10x Faster TypeScript

#145
post #105

Earlier quoted context omitted.

C# needs an interpreter (.NET runtime) while Go compiles down to a binary. And the toolchain allows you to compile for other architectures fairly easily. So that could be a fundamental reason why.

.NET has AOT compilation now. There really is no excuse, especially when you consider that C# has a pretty decent type system and Go has an ad-hoc, informally specified, bug-ridden, slow implementation of half of a decent type system.

> Go has an ad-hoc, informally specified, bug-ridden, slow implementation of half of a decent type system.

It's not lost on me that this is a widely used aphorism. The problem is that it's not true in any way shape or form.

Re: A 10x Faster TypeScript

#146
post #16

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.

Why not AOT compiled C#, given the team's historical background?

Seeing that Hejlsberg started out with Turbo Pascal and Delphi, and that Go also has a lot of Pascal-family heritage, he might hold some sympathy for Go as well...

Re: A 10x Faster TypeScript

#147

Earlier quoted context omitted.

look, not to argue with a stranger on hacker news, lol, but genuine calm question here: is this really a helpful nit? I know what you're getting at but the blogpost itself doesn't imply that JavaScript is 10x faster. I could complain, about your suggested change, that it's really `build and typecheck` time. It's a title. Sometimes they don't have _all_ the context. That's ok.

Unfortunately many people only look at headlines, so titles do matter. People take them at face value.

yes, and TypeScript is not JavaScript. Objectively, every element of _TypeScript_, strictly speaking, is well known to be separate.

Re: A 10x Faster TypeScript

#148
post #16

Earlier quoted context omitted.

Why not AOT compiled C#, given the team's historical background?

I'm not involved in the decisions, but don't C# applications have a higher startup time and memory usage? These are important considerations for a compiler like this that needs to start up and run fast in e.g. new CI/CD boxes. For a daemon like an LSP I reckon C# would've worked.

Not when compiled by NativeAOT. It also produces smaller binaries than Go and has better per-dependency scalability (due to metadata compression, pointer-rich section dehydration and stronger reachability analysis). This also means you can use F# too for this instead, which is excellent for langdev (provided you don't use printf "%A" which is incompatible which is a small sacrifice).

Re: A 10x Faster TypeScript

#149
post #16

Earlier quoted context omitted.

Why not AOT compiled C#, given the team's historical background?

I'm not involved in the decisions, but don't C# applications have a higher startup time and memory usage? These are important considerations for a compiler like this that needs to start up and run fast in e.g. new CI/CD boxes. For a daemon like an LSP I reckon C# would've worked.

Native AOT exists, and C# has many C++ like capabilities, so not at all.

Re: A 10x Faster TypeScript

#150
post #137

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"

Yea, sounds like cross platform AOT compiled C# not being mature and performant was a big reason that C# was rejected. One other thing I forgot to mention was that he talked about how the current compiler was mostly written as more or less pure functions operating on data structures, as opposed to being object oriented, and that this fits very well with the Go way of doing things, making 1:1 port much easier.

> sounds like cross platform AOT compiled C# not being mature and performant was a big reason

I don't think it was the performance. C# is usually on par or faster than Go.

Could be the lack of maturity but also that I believe Go produces smaller binaries which makes a lot of sense for a CLI.

Post reply on HN