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

601–610 of 943 posts

Re: A 10x Faster TypeScript

#601

Post by mappu »

zozbot234 wrote: post #592
mappu wrote: post #547

Earlier quoted context omitted.

The major roadblocks for WasmGC in Golang at the moment are (A) Go expects a non-moving GC which WasmGC is not obligated to provide; and (B) WasmGC does not support interior pointers, which Go requires. https://github.com/golang/go/issues/63904#issuecomment-22536...

These are no different than the issues you'd have in any language that compiles to WasmGC, because the new GC'd types are (AIUI) completely unrelated to the linear "heap" of ordinary WASM - they are pointed to via separate "reference" types that are not 'pointers' as normally understood. That whole part of the backend has to be reworked anyway, no matter what your source language is.

Go exposes raw pointers to the programmer, so from your description i think those semantics are too rudimentary to implement Go's semantics, there would need to be a WasmGC 2.0 to make this work.

It sounds like it would be a great fit for e.g. Lua though.

Re: A 10x Faster TypeScript

#602

Post by nipah »

rat9988 wrote: post #590
nipah wrote: post #510

Earlier quoted context omitted.

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 nowada…

> But they not stated it is of C#'s performance But I just said my point is not about performance at all! It is about the whole package. Performance of c# and go are both enough for my usecase, same for java and c obviously. They just told us that they don't think the whole package makes sense, and disowned the AOT compilation.

But you said: > I was trying ot push .net as our possible language for somehow high performance executables. Seeing this means I'll stop trying to advocate for it. If even this team doesn't believe in it.

Which made me naturally think your point was, indeed, about performance. Although as it appears to be, I'm wrong, so it's fair enough.

Re: A 10x Faster TypeScript

#603

Post by magicalist »

neonsunset wrote: post #520
mike_hearn wrote: post #518

Earlier quoted context omitted.

I wonder if there's just some cultural / generational stuff happening there too. The fact that the TS compiler is all about compiling a highly complex OOP/functional hybrid language yet is said to use neither objects nor FP seems rather telling. Hejlsberg is famous for designing object oriented languages (Delphi, C#) but the Delphi compiler itself was written largely in assembly, and the C# compiler was for a very lo…

> Roslyn It was introduced back then with .NET Framework 4.6 (C# 6) - a loong time ago (July 2015). The OSS .NET has started with Roslyn from the very beginning. > And the Java AOT compiler (native image) is not only fully written in Java itself, everything from optimizations to code generation, but even the embedded runtime is written in Java too. NativeAOT uses the same architecture. There is no C++ besides GC and…

> In the end, it is the TypeScript team members who worked on this port, not Anders Hejlsberg himself, which is my understanding

no? https://github.com/microsoft/typescript-go/graphs/contributo...

Re: A 10x Faster TypeScript

#605

Post by dwaltrip »

owebmaster wrote: post #367
hoten wrote: post #133

Earlier quoted context omitted.

Maybe they aren't the audience. I don't see how this is ambiguous to anyone that actually uses typescript

deno runs typescript and it won't run 10x faster. It is ambiguous.

It seems Deno compiles typescript to JS just like everyone else.

https://docs.deno.com/runtime/fundamentals/typescript/

Re: A 10x Faster TypeScript

#606

Post by neonsunset »

magicalist wrote: post #603
neonsunset wrote: post #520

Earlier quoted context omitted.

> Roslyn It was introduced back then with .NET Framework 4.6 (C# 6) - a loong time ago (July 2015). The OSS .NET has started with Roslyn from the very beginning. > And the Java AOT compiler (native image) is not only fully written in Java itself, everything from optimizations to code generation, but even the embedded runtime is written in Java too. NativeAOT uses the same architecture. There is no C++ besides GC and…

> In the end, it is the TypeScript team members who worked on this port, not Anders Hejlsberg himself, which is my understanding no? https://github.com/microsoft/typescript-go/graphs/contributo...

Ah, I see. Thanks for the clarification. Well, doubly unfortunate then. I wonder if we'll ever know what happened behind the scenes.

Re: A 10x Faster TypeScript

#607

Post by yakz »

vips7L wrote: post #599
almosthere wrote: post #523

Earlier quoted context omitted.

.NET executables requires a runtime environment to be installed. Go executables do not. TSC is installed in too many places for that burden to be placed all of a sudden. It is the same reason why Java has had a complicated acceptance history too. It's fine in the places that it is pre-installed, but no where else. Node/React/Typescript developers do not want to install .net all of a sudden. If you react that poorly,…

.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.

Re: A 10x Faster TypeScript

#608

Post by dcre »

1oooqooq wrote: post #556
dcre wrote: post #128

Earlier quoted context omitted.

In the embedded video they show some of the code side by side and it is just a ton of if statements. https://youtu.be/pNlq-EVld70?si=UaFDVwhwyQZqkZrW&t=323

to be fair, there's not many ways to implement a token matcher. though looking at that flood of loose ifs+returns, i kinda wish they used rust :)

I’d guess Rust compile times weren’t worth it if they weren’t going to be taking advantage of the type system in interesting ways.

Re: A 10x Faster TypeScript

#609

Post by Tadpole9181 »

hansifer wrote: post #568
Tadpole9181 wrote: post #334

Earlier quoted context omitted.

It is quite literally a separate language. Python's type hints are a part of the Python specification and all valid Python type hints will run in any compliant Python runtime. Typescript is not, in any way, valid JavaScript. The moment you add any type syntax, you can no longer run the code in Node or Browsers without enabling a special preprocess step.

Do you think JSX is a separate language?

Yes, JSX is a superset of JS and will not work in any tooling that is not explicitly JSX compatible. JS grammars will not parse it, it's not standard.

Re: A 10x Faster TypeScript

#610

Post by Izkata »

fastball wrote: post #130
pseudopersonal wrote: post #60

Earlier quoted context omitted.

Thanks for the clarification. For those of us who don't use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn't know if it's about a compiler or a runtime. What if they announced a bun competitor? https://betterstack.com/community/guides/scaling-nodejs/node... .

Those are javascript runtimes, not TypeScript runtimes. The point stands. If you don't know enough about TypeScript to understand that TypeScript is not a runtime, I'm not sure why you would care about TypeScript being faster (in either case).

I thought the title was announcing someone created a Typescript runtime. It is misleading.

Preact was "a faster React", for example.

Post reply on HN