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

501–510 of 943 posts

Re: A 10x Faster TypeScript

#501

Post by jamescrowley »

textlapse wrote: post #464
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.

I am curious why dotnet was not considered - it should run everywhere Go does with added NativeAoT too, so I am especially curious given the folks involved ;) (FWIW, It must have been a very well thought out rationale.) Edit: watched the revenant clip from the GH discussion- makes sense. Maybe push NativeAoT to be as good? I am (positively) surprised Hejlsberg has not used this opportunity to push C#: a rarity in the…

Discussion and video link here for anyone else interested: https://github.com/microsoft/typescript-go/discussions/411#d...

And lightly edited transcript here: https://github.com/microsoft/typescript-go/discussions/411#d...

Re: A 10x Faster TypeScript

#503

Post by loevborg »

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.

Congrat on the announcement, this is a great achievement!

Re: A 10x Faster TypeScript

#504

Post by neonsunset »

valcron1000 wrote: post #462
thund wrote: post #209

Earlier quoted context omitted.

Honest q, which part is out of date and why? Thanks

Pretty much everything: > While C# does have AOT capabilities nowadays this is not as mature as Go's and not all platforms support it https://learn.microsoft.com/en-us/dotnet/core/deploying/nati... Only Android is missing from that list (marked as "Experimental"). We could argue about maturity but this is a bit subjective. > Go also has somewhat better control over data layout How? C# supports structs, ref structs (s…

Chances are it was just personal preference of the team and decades of arguing about language design have worn out Anders Hejlsberg. I don't think structural typing alone is enough of an argument to justify the choice over Rust. Maybe the TS team thought choosing Go would have better optics. Well, they won't have it both ways because clearly this decision in my opinion is short-sighted and as someone aptly pointed on twitter they will be now beholden to Google's control over Go should they ever need compiler to support a new platform or evolve in a particular way. Something they would've gotten easily with .NET.

Re: A 10x Faster TypeScript

#505

Post by bitmasher9 »

nailer wrote: post #362
bitmasher9 wrote: post #355

Earlier quoted context omitted.

My favorite benefit of Go over C# is that I don’t have to carry around a dotnet runtime to every service that touches my Typescript code.

Can't the CLR tools just output native binaries now?

Can it? That’s awesome.

Mostly these days I’m only aware of C# when it inconveniences me.

Re: A 10x Faster TypeScript

#506

Post by paxys »

Faster compilation is great, but what I'm really excited for is a faster TS Language Server. Being able to get autocomplete hints, hover info, goto definition, error squiggles and more anything close to 10x faster is going to be revolutionary when working in large TS codebases.

Re: A 10x Faster TypeScript

#507

Post by conartist6 »

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.

Hi Daniel!

Really interesting news, and uniquely dismaying to me as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystem.

My question has to do with Ryan's statement:

> We also considered hybrid approaches where certain components could be written in a native language, while keeping core typechecking algorithms in JavaScript

I've experimented deeply in this area (maybe 15k hours invested in BABLR so far) and what I've found is that it's richly rewarding. Javascript is fast enough for what is needed, and its ability to cache on immutable data can make it lightning fast not through doing more work faster, but by making it possible to do less work. In other words, change the complexity class not the constant factor.

Is this a direction you investigated? What made you decide to try to move sideways instead of forwards?

Re: A 10x Faster TypeScript

#508

Post by mavelikara »

DanRosenwasser wrote: post #59
no_wizard wrote: post #42

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…

Thanks for the thoughtful response!

Re: A 10x Faster TypeScript

#509

Post by mike_hearn »

spankalee wrote: post #412
pjmlp wrote: post #84

Earlier quoted context omitted.

Thanks, but it really doesn't clarify why a team with roots on the .NET ecosystem decided C#/Native AOT isn't fit for purpose.

I don't understand what Anders' past involvement with C# has to do with this. Would the technical evaluation be different if done by Anders vs someone else?

C# and Go are direct competitors and the advantages of Go that were cited are all features of C# as well, except the lack of top level functions. That's clearly not an actual problem: you can just define a class per file and make every method static, if that's how you like to code. It doesn't require any restructuring of your codebase. There's also no meaningful difference in platform support, .NET AOT supports Win/Mac/Linux on AMD64/ARM i.e. every platform a developer might use.

He clearly knows all this so the obvious inference is that the decision isn't really about features. The most likely problem is a lack of confidence in the .NET team, or some political problems/bad blood inside Microsoft. Perhaps he's tried to use it and been frustrated by bugs; the comment about "battle hardened" feel like where the actual rationale is hiding. We're not getting the full story here, that's clear enough.

I'm honestly surprised Microsoft's policies allowed this. Normally companies have rules that require dogfooding for exactly this reason. Such a project is not terribly urgent, it has political heft within Microsoft. They could presumably have got the .NET team to fix bugs or make optimizations they need, at least a lot easier than getting the Go team to do it. Yet they chose not to. Who would have any confidence in adoption of .NET for performance sensitive programs now? Even the father of .NET doesn't want to use it. Anyone who wants to challenge a decision to adopt it can just point at Microsoft's own actions as evidence.

Re: A 10x Faster TypeScript

#510

Post by nipah »

rat9988 wrote: post #282
surajrmal wrote: post #185

Earlier quoted context omitted.

They cited code style and porting as reasons to use go over c#, not performance.

I didn't say it was very performance critical, go and c# are both good enough for us in this regard. The problem is that, when evaluating the whole thing, they decided against c#, that is problematic here.

But they not stated it is of C#'s performance, so I don't think this is THAT problematic. But I agree that it would be fine to see them dogfeeding on their language for such a massive project, and a project that is even related to TypeScript (as it inspired it in some features), it is a shame they don't do it, but it is also the case for many of their projects (like, they are even pushing react native for apps nowadays), so I think at some level it's really fine.
Post reply on HN