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

631–640 of 943 posts

Re: A 10x Faster TypeScript

#631

Post by alpaca128 »

mmcnl wrote: post #472
ggus wrote: post #451

Earlier quoted context omitted.

Agree. TypeScript is primarily a programming language. Did they make the language faster? No. Hence, the title is misleading.

For anyone who uses TypeScript on a daily basis it's not ambiguous at all. Everyone who works with TS knows the runtime code is JavaScript code that is generated by the TypeScript compiler. And it's also pretty common knowledge that JavaScript is quite fast, but TS itself is not.

And if this post was about a TS compiler that emitted x86 executables you would be wrong and find out that it is indeed ambiguous.

Re: A 10x Faster TypeScript

#632

Post by breadwinner »

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…

So when can we expect Go support in Visual Studio? I am sold by Anders' explanation that Go is the lowest language you can use that has garbage collection!

Re: A 10x Faster TypeScript

#633

Post by neonsunset »

neonsunset wrote: post #504
valcron1000 wrote: post #462

Earlier quoted context omitted.

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…

To correct myself, someone pointed out a commit graph which indicates Anders Hejlsberg's heavy involvement with the ongoing port efforts: https://github.com/microsoft/typescript-go/graphs/contributo...

Re: A 10x Faster TypeScript

#634

Post by metaltyphoon »

reactordev wrote: post #550
pjmlp wrote: post #253

Earlier quoted context omitted.

Just like Go, there is no magic here. Where do you think Go gets those chubby static linked executables from? That people have to apply UPX on top.

Go’s static binaries are orders of magnitude smaller than .Net’s static binaries. However, you are right, all binaries have some bloat in order to make them executable.

This is flat out incorrect if you are doing AOT in C#

Re: A 10x Faster TypeScript

#635

Post by jillyboel »

noodletheworld wrote: post #51
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.

Go is quite difficult to embed in other applications due to the runtime. What do you see as the future for use cases where the typescript compiler is embedded in other projects? (Eg. Deno, Jupyter kernels, etc.) There’s some talk of an inter process api, but vague hand waving here about technical details . What’s the vision ? In TS7 will you be able to embed the compiler? Or is that not supported?

Javascript is also quite difficult to embed in other applications. So not much has changed, except it's no longer your language of choice.

Re: A 10x Faster TypeScript

#636

Post by vips7L »

yakz wrote: post #607
vips7L wrote: post #599

Earlier quoted context omitted.

.NET has been able to build a self contained single file executable for both the JIT and AOT target for a quite some time. Java also does not require the user to install a runtime. JLink and JPackage have both been around for a long time.

Maybe some other runtimes do this or it has been changed, but in the past self-contained singe-file .NET deployment just meant that it rolled all the files up during publishing and when you run it, it extracted them to a folder. Not really like a single statically linked executable.

It hasn't done that in years.

Re: A 10x Faster TypeScript

#638

Post by tacticus »

pier25 wrote: post #456
xandrius wrote: post #353

Earlier quoted context omitted.

I never heard C# being fasted than Go, except on certain batched jobs and even there Go can be better.

For example, look at the Techempower benchmarks. I benchmarked HTML rendering and Dotnet was 2-3x faster than Go using either Templ or html/template. Etc.

The c# benchmarks where they didn't use the framework to do any of the actual templating?

those hardcoded byte arrays are how everyone does templating everywhere right?

or are you talking about after they changed back their "platform" test to not do that and is substantially slower than go

https://dusted.codes/how-fast-is-really-aspnet-core

Re: A 10x Faster TypeScript

#639

Post by seanmcdirmid »

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…

> It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further

Typescript's type system is unsound so it probably will never be very useful for an optimizing compiler. That was never the point of TS however.

Re: A 10x Faster TypeScript

#640

Post by i_s »

mike_hearn wrote: post #509
spankalee wrote: post #412

Earlier quoted context omitted.

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/M…

Yea, I came here to say the same thing. Anders' reasons for not going with C# all seem either dubious or superficial and easily worked around.

First he mentions the no classes thing. It is hard to see how that would matter even for automated porting, because like you said, he could just use static classes, and even do a static using statement on the calling side.

Another one of his reasons was that Go was good at processing complex graphs, but it is hard to imagine how Go would be better at that than C#. What language feature that Go has, but C# does not supports that? I don't think anyone will be able to demonstrate one. This distinction makes sense for Go vs Rust, but not for Go vs C#.

As for the platform / AOT argument, I don't know as much about that, but I thought it was supposed to be possible now. If it isn't, it seems like it would be better for Microsoft to beef that up than to allow a vote of no confidence to be cast like this.

Post reply on HN