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

611–620 of 943 posts

Re: A 10x Faster TypeScript

#611

Post by wokwokwok »

nine_k wrote: post #378
noodletheworld wrote: post #51

Earlier quoted context omitted.

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?

Why embed it if you can run a process alongside yours and use efficient IPC? I suppose the compiler code should not be in some tight loop where an IPC boundary would be a noticeable slowdown. Compilation occurs relatively rarely, compared to running the compiled code, in things like Node / Deno / Bun / Jupyter. LSPs use this model with a pretty wasteful XML IPC, and they don't seem to feel slow.

Because running a parallel process is often difficult. In most cases, the question becomes:

So, how exactly is my app/whatever supposed to spin up a parallel process in the OS and then talk to it over IPC? How do you shut it down when the 'host' process dies?

Not vaguely. Not hand wave "just launch it". How exactly do you do it?

How do you do it in environments where that capability (spawning arbitrary processes) is limited? eg. mobile.

How do you package it so that you distribute it in parallel? Will it conflict with other applications that do the same thing?

When you look at, for example, a jupyter kernel, it is already a host process launched and managed by jupyter-lab or whatever, which talks via network chatter.

So now each kernel process has to manage another process, which it talks to via IPC?

...

Certainly, there are no obvious performance reasons to avoid IPC, but I think there are use cases where having the compiler embedded makes more sense.

Re: A 10x Faster TypeScript

#612

Post by [deleted] »

muglug wrote: post #589
aylmao wrote: post #558

Earlier quoted context omitted.

This is awesome. Thanks to you and all the TypeScript team for the work they put on this project! Also, nice to see you here, engaging with the community. Porting to Go was the right decision, but part of me would've liked to see a different approach to solve the performance issue. Here I'm not thinking about the practicality, but simply about how cool it would've been if performance had instead been improved via: -…

Not Daniel, but I've ported a typechecker from PHP to Rust (with some functional changes) and also tried working with the official Hack OCaml-based typechecker (a precursor to Flow). Rust and OCaml are _maybe_ prettier to look at, but for the average TypeScript developer Go is a much more understandable target IMO. Lifetimes and ownership are not trivial topics to grasp, and they add overhead (as discussed here: http…

[deleted]

Re: A 10x Faster TypeScript

#613

Post by nightpool »

pjmlp wrote: post #12

Even though I have my considerations regarding Go, I love that they picked Go instead of the fashion to go Rust that seems to be the norm now. A compiled managed language is much better approach for userspace applications. Pity that they didn't go with AOT compiled .NET, though.

Hejlsberg discusses the decision not to use C# here: https://www.youtube.com/watch?v=10qowKUW82U&t=1154s

Re: A 10x Faster TypeScript

#614

Post by ricardobeat »

bdangubic wrote: post #485
jay_kyburz wrote: post #480

Earlier quoted context omitted.

It's a bad look for both C# and TypeScript. Anybody starting a new code base now would be looking for ways to avoid both and jump right to Go.

if I had to use Go I’d change my career and go do some gardening :)

I'd probably have said the same 5 years ago, it's surprising how easy you change sides once you actually use it in a team.

Re: A 10x Faster TypeScript

#615

Post by jodrellblank »

uticus wrote: post #453
jodrellblank wrote: post #352

Earlier quoted context omitted.

> "given that C# was famously created by the guy writing the blog post" What is this logic? "You worked on C# years ago so you must use C# for everything"? "You must dictate C# to every team you lead forever, no matter what skills they have"? "You must uphold a dogma that C# is the best language for everything, because you touched it last"? Why aren't you using this logic to argue that they should use Delphi or Turbo…

Yes, but C# is the Microsoft language, and I would say TypeScript is 2nd place Microsoft language (sorry F# folks - in terms of popularity not objective greatness of course). So it's not just that the lead architect of C# is involved in the TypeScript changes. It's also that this is under the same roof and the same sign hangs on the building outside for both languages. If Ford made a car and powered it with a Chevy e…

> "So it's not just that the lead architect of C# is involved in the TypeScript changes."

Anders Hejlsberg hasn't been the lead architect of C# for like 13 years. Mads Torgersen is:

https://dotnetcore.show/episode-104-c-sharp-with-mads-torger... - "I got hired by Microsoft 17 years ago to help work on C#. First, I worked with Anders Hejlsberg, who’s sort of the legendary creator and first lead designer of C#. And then when he and I had a little side project with others to do TypeScript, he stayed over there. And I got to take over as lead designer C#. So for the last, I don’t know, nearly a decade, that’s been my job at Microsoft to, to take care of the evolution of the C# programming language"

Years later, "why aren't you using YOUR LANGUAGE, huh? What's the matter, you don't like YOUR LANGUAGE?" is pushy and weird; he's a person with a job, not a religious cult leader.

> "If Ford made a car and powered it with a Chevy engine, wouldn't you be curious what was going on also?"

Like these? https://www.slashgear.com/1642034/fords-powered-by-non-ford-...

Re: A 10x Faster TypeScript

#616

Post by 9rx »

nipah wrote: post #529
9rx wrote: post #286

Earlier quoted context omitted.

> Because of its truly primitive type system That is the main reason they gave for why they those chose Go. The parent asked "Why _not_ use Go?"

This is not "the main reason", lol, it was never stated as such. The type system could be way more powerful and, having the same general features they would probably had still picked it up.

What realistic contender doesn't have all the same general features as Go? It doesn't exactly have many to choose from, none of them particularly esoteric, and most of them bare necessities required of any language.

Let's be real: You can absolutely write "Go-style" code in just about any language that might have been considered for this. But you wouldn't want to, as a more advanced type system enables entirely different idioms, and it is in bad faith to other developers (including future you) to stray too far from those idioms. If ignoring idioms doesn't sound like a bad idea on day one, you'll feel the hurt and regret soon enough...

Go was chosen because the idioms are generally in alignment with their needs and those idioms are wholly dependent on the shape of its type system.

Re: A 10x Faster TypeScript

#618

Post by xanth »

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…

Unfortunately many TS users have a surface level understanding of TS leading them to believe that TS is "real"

Re: A 10x Faster TypeScript

#619

Post by ricardobeat »

zigzag312 wrote: post #436
cardanome wrote: post #383

Earlier quoted context omitted.

They are still going to significant bigger than the equivalent golang binary because of the huge .NET runtime, no?

https://github.com/MichalStrehovsky/sizegame C#: 945 kB Go: 2174 kB

Is this a fair comparison, won't doing anything more significant than `print` in C# require a .NET framework to be installed (200MB+)?

Re: A 10x Faster TypeScript

#620

Post by bdangubic »

ricardobeat wrote: post #614
bdangubic wrote: post #485

Earlier quoted context omitted.

if I had to use Go I’d change my career and go do some gardening :)

I'd probably have said the same 5 years ago, it's surprising how easy you change sides once you actually use it in a team.

I was mostly joking… some of the most amazing shit code-wise I have seen in “non-mainstream” languages (fortran leads the way here)
Post reply on HN