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

741–750 of 943 posts

Re: A 10x Faster TypeScript

#741

Post by jay_kyburz »

sethaurus wrote: post #666
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.

I'm struggling to understand how this is a bad look for Typescript. Do you mean that the specific choice of Go reflects poorly on Typescript, or just the decision to rewrite the compiler in a different non-TS language? If it's the latter, I think the pitch of TS remains the same — it's a better way of writing JS, not the best language for all contexts.

I think a lot of folks downplay the performance costs for the convenience of a shared code-base between the front and backend.

If the TS team is getting a 10x improvement moving from TS to Go, you might imagine you could save about 10x on your server cpu. Or that your backend would be 10x more responsive.

If you have dedicated team for front and back anyhow, is a 10x slow down really worth a shared codebase?

Re: A 10x Faster TypeScript

#742

Post by bilekas »

selfmodruntime wrote: post #720
emseetech wrote: post #680

Earlier quoted context omitted.

| with no frills. People say this like it's a bad thing. It's not, it's Go's primary strength.

Yes. For Webservers. Not for compilers. I wrote a bunch of compilers, and Go is not a language I would choose for this.

Go is exceptionally fast for a transpiler. Esbuild is a great example.. Rust would offer any significant gains vs adoption for support.

Re: A 10x Faster TypeScript

#743

Post by anileated »

zoogeny wrote: post #519
throwitaway1123 wrote: post #474

Earlier quoted context omitted.

> First, they are using WASM which itself is a a low-level representation. WASM is used to generate the query plan, but query execution now happens entirely within TypeScript, whereas under the previous architecture both steps were handled by Rust. So in a very literal sense some of the Rust code is being rewritten in TypeScript. > Basically, if the majority of your application is already in JavaScript and expects pr…

I'm not denying the facts of the matter, I am denying the conclusion. The circumstances of the situation are relevant. Marshalling cost across IPC boundaries come into play in every single possible situation regardless of language. It is why shared memory architectures exist. It doesn't matter what language is on the other side of the IPC, if the performance gained by using a separate process is not greater than the…

The fact that many software products are moving to lower-level languages is not a general point in favour of lower-level languages being somehow better—rather, it simply aligns with general directions of software evolution.

1. As products mature, they may find useful scenarios involving runtime environments that don’t necessarily match the ones that were in mind back when the foundation was laid. If relevant parts are rewritten in a lower-level language like C or Rust, it becomes possible to reuse them across environments (in embedded land, in Web via WASM, etc.) without duplicate implementations while mostly preserving or even improving performance and unlocking new use cases and interesting integrations.

2. As products mature, they may find use cases that have drastically different performance requirements. TypeScript was not used for truly massive codebases, until it was, and then performance became a big issue.

Starting a product trying to get all of the above from the get go is rarely a good idea: a product that rots and has little adoption due to feature creep and lack of focus (with resulting bugs and/or slow progress) doesn’t stand a chance against a product that runs slower and in fewer environments but, crucially, 1) is released, 2) makes sound design decisions, and 3) functions sufficiently well for the purposes of its audience.

Whether LLMs are involved or not makes no meaningful difference: no matter how good your autocomplete is, other things equal the second instance still wins over the first—it still takes less time to reach the usefulness threshold and start gaining adoption. (And if you are making a religious argument about omniscient entities for which there is no meaningful difference between those two cases, which can instantly develop a bug-free product with infinite flexibility and perfect performance at whatever the level of abstraction required, coming any year, then you should double-check whether if they do arrive anyone would still be using them for this purpose. In a world where I, a hypothetical end user, can get X instantly conjured for me out of thin air by a genie, you, a hypothetical software developer, better have that genie conjure you some money lest your family goes hungry.)

Re: A 10x Faster TypeScript

#744

Post by lossolo »

dustedcodes wrote: post #409
tinco wrote: post #61

Earlier quoted context omitted.

It's not just a pity, it's very surprising. In my eyes Go is a direct competitor of C#. Whenever you pick Go for a project, C# should have been a serious consideration. Hejlsberg designed C# and that a team that he's an authority figure in would opt to use Go, a language which frankly I would not consider to build a compiler in is astounding. Not saying that in a judgemental way, I'm just genuinely surprised. What do…

C# has become a poor jack of all trades, trying to be Java, Go and F# at the same time and actually being a shity poor version of all of them. On top of that .NET has become a very enterprisey bloatware. In all honesty, I'm not surprised that they went with Go, as it has a clear identity, a clear use-case which it caters for extremely well and doesn't lose focus with trying to be too many other unrelated things at th…

If not for Microsoft's backing, C# would have died a long time ago. It's just another D, but with a lot more money behind it. It had its chance/momentum, but it failed, and its time has passed. Resurrecting the language now would be very difficult.

Re: A 10x Faster TypeScript

#745

Post by ryanjshaw »

zigzag312 wrote: post #406
dagw wrote: post #338

Earlier quoted context omitted.

Hejlsberg seemed quite negative when it came to cross platform AOT compiled C# in several comments he's made, hinting at problems with both performance and maturity on certain platforms.

Projects like this are needed to improve C#'s cross platform AOT. Missed opportunity IMO.

Absolutely. Go is where it is because of the parent org's commitment to dogfooding it; strange that Microsoft is wasting this opportunity AND sending a negative message to .NET devs.

Re: A 10x Faster TypeScript

#746

Post by wiseowise »

aib wrote: post #731

Just tried it on our codebase. Getting over a thousand errors, a good portion of which seem to be: ../../../tmp/typescript-go/built/local/lib.dom.d.ts:27982:6 - error TS2300: Duplicate identifier 'KeyType'. 27982 type KeyType = "private" | "public" | "secret"; ~~~~~~~ ../../../tmp/typescript-go/built/local/lib.webworker.d.ts:9370:6 - 'KeyType' was also declared here. 9370 type KeyType = "private" | "public" | "secret…

> Running it in another portion results in SIGSEGV with a bad/nil pointer defererence, which puts me in the camp of people questioning the choice of Go.

They would be still setting up the project, if it was Rust.

Re: A 10x Faster TypeScript

#747

Post by sethaurus »

nailer wrote: post #365

Keep in mind most apps made in frameworks aren't using `tsc` but rather existing tools like `esbuild` which are native binaries.

That's true of the compilation step, but type-checking always uses `tsc`. They're no TS spec, so it's very hard to build a fully-compatible competing implementation. Erasing the types syntactically is a lot easier.

Re: A 10x Faster TypeScript

#748

Post by zombot »

austin-cheney wrote: post #535
sebzim4500 wrote: post #496

Earlier quoted context omitted.

How do you reconcile this view with the fact that the typescript team rewrote the compiler in Go and it got 10x faster? Do you think that they could have kept in in typescript and achieved similar performance but they didn't for some reason?

I have no idea about the details of their test cases. If they had used an even faster language like Cobol or Fortran maybe they could have gotten it 1,000,000x faster. What I do know is that some people complain about long compile times in their code that can last up to 10 minutes. I had a personal application that was greater than 60k lines of code and the tsc compiler would compile it in about 13 seconds on my supe…

> maybe they could have gotten it 1,000,000x faster.

WTF.

Re: A 10x Faster TypeScript

#749

Post by cxr »

pizlonator wrote: post #113
AshleysBrain wrote: post #64

Earlier quoted context omitted.

Well-optimized JavaScript can get to within about 1.5x the performance of C++ - something we have experience with having developed a full game engine in JavaScript [1]. Why is the TypeScript team moving to an entirely different technology instead of working on optimizing the existing TS/JS codebase? [1] https://www.construct.net/en

Your JS code is way uglier than their Go code, if you're doing those kinds of shenanigans. JS is 10x-100x slower than native languages (C++, Go, Rust, etc) if you write the code normally (i.e. don't go down the road of uglifying your JS code to the point where it's dramatically less pleasant to work with than the C++ code you're comparing to).

There's no such thing as a native language unless you're talking about machine code.

It's kind of annoying how even someone like Hejlsberg is throwing around words like "native" in such an ambiguous, sloppy, and prone-to-be-misleading way on a project like this.

"C++" isn't native. The object code that it gets compiled to, large parts of which are in the machine's native language, is.

Likewise "TypeScript" isn't non-native in any way that doesn't apply to any other language. The fact that tsc emits JS instead of the machine's native language is what makes TypeScript programs (like tsc itself) comparatively slow.

It's the compilers that are the important here, not the languages. (The fact that the TypeScript team was committed to making sure the typescript-go compiler is the same (nearly line-for-line equivalent) to the production version of the TypeScript compiler written in itself really highlights this.)

Post reply on HN