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

341–350 of 943 posts

Re: A 10x Faster TypeScript

#341

Post by blueredmodern »

hedora wrote: post #264
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 an extremely strange choice, given the ecosystem you're targeting. I've got quite a bit of experience in it, TS, Rust and C++. I'd pick any of those for productivity and (in the case of C++ and Rust, thread-safety) over Go, simply because Go's type system is so impoverished. From a performance perspective, I'd expect C++ and Rust to be much easier targets too, since I've seen quite a few industrial Go services…

[dead]

Re: A 10x Faster TypeScript

#342

Post by ZeWaka »

colonelspace wrote: post #270
sapiogram wrote: post #239

Earlier quoted context omitted.

> I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language. Software never gets rewritten in a higher level language, but software is constantly replaced by alternatives. First example that comes to mind is Discord, an Electron app that immediately and permanently killed every other voice client on the market when it launched.

> Discord ... immediately and permanently killed every other voice client on the market Do you mean voice clients like FaceTime, Zoom, Teams, and Slack?

They're talking about TeamSpeak, Vent, Mumble, and Skype.

Re: A 10x Faster TypeScript

#343

Post by aaronmu »

reverseblade2 wrote: post #197

Just use fable and F# instead, your code transpiles to python and rust too

For the small price of 10x slower tooling.

I’ve been using F# full-time for 6 years now. And compiler/tooling gets painfully slow fast.

Still wouldn’t trade it for anything else though.

Re: A 10x Faster TypeScript

#344

Post by Tadpole9181 »

zoogeny wrote: post #230

I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…

The JS `tsc` type checks the entire 1.5 million line VS Code source in 77s (non-incremental). 7s is a lot better and will certainly imrpove DX - which is their goal - but I don't see how that's "insufficient".

The trade-off is that the team will have to start dealing with a lot of separate issues... How do tools like ESLint TS talk to TSC now? How to run this in playground? How to distribute the binaries? And they also lose out on the TS type system, which makes their Go version rely a little more on developer prowess.

This is an easy choice for one of the most fundamental tools underlaying a whole ecosystem, maintained by Microsoft and one of the developers of C# itself, full-time.

Other businesses probably want to focus on actually making money by leading their domain and easing long-term maintenance.

Re: A 10x Faster TypeScript

#345

Post by zoogeny »

throwitaway1123 wrote: post #320
zoogeny wrote: post #230

I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…

> I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language. Prisma is currently being rewritten from Rust to TypeScript: https://www.prisma.io/blog/rust-to-typescript-update-boostin... > Yet projects inevitably get to the stage where a more native representation wins out. I would be careful about extrapolating the performance gains achieved b…

I think the Prisma case is a bit of a red herring. First, they are using WASM which itself is a a low-level representation. Second, the performance gains appear primarily in avoiding the marshalling of data from JavaScript into Rust (and back again I presume). Basically, if the majority of your application is already in JavaScript and expects primarily to interact with other code written in JavaScript, it usually doesn't make sense to serialize your data, pass it to another runtime for some processing, then pass the result back.

As for the "compilers are special" reasoning, I don't ascribe to it. I suppose because it implies the opposite: something (other than a compiler) is especially suited to run well in a scripting language. But the former doesn't imply the later in reality and so the case should be made independently. The Prisma case is one: you are already dealing with JavaScript objects so it is wise to stay in JavaScript. The old cases I would choose the scripting language (familiarity, speed of adding new features, ability to hire a team quickly) seem to be eroding in the face of LLMs.

Re: A 10x Faster TypeScript

#346

Post by nine_k »

Starlord2048 wrote: post #211

[flagged]

Go with parametric types is already a reasonably expressive language. Much more expressive than C in which a number of compilers has been written, at least initially; not everyone had the luxury of using OCaml or Haskell.

There is already a growing number of native-code tools of the JS/TS ecosystem, like esbuild or swc.

Maybe we should expect attempts of native AOT compilation for TS itself, to run on the server side, much like C# has an AOC native-code compiler.

Re: A 10x Faster TypeScript

#347

Post by styfle »

eapriv wrote: post #25

It’s not obvious from the text, but the compiler was previously written in TypeScript (which was kind of a strange choice for the language to write a compiler in).

Its not strange, its very common. Its called "bootstrapping".

> Bootstrapping is a fairly common practice when creating a programming language. Many compilers for many programming languages are bootstrapped, including compilers for ALGOL, BASIC, C, C#, Common Lisp, D, Eiffel, Elixir, Go, Haskell, Java, Modula-2, Nim, Oberon, OCaml, Pascal, PL/I, Python, Rust, Scala, Scheme, TypeScript, Vala, Zig and more.

https://en.wikipedia.org/wiki/Bootstrapping_(compilers)

Re: A 10x Faster TypeScript

#348

Post by xandrius »

sapiogram wrote: post #239
zoogeny wrote: post #230

I notice this time and time again: projects start with a flexible scripting language and a promise that the performance will be sufficient. I mean, JS is pretty performant as scripting languages go and it is hard to think of any language runtimes that get more attention than the browser VMs. And generally, 90% of the things people do will run sufficiently fast in that VM. Yet projects inevitably get to the stage wher…

> I mean, I can't think of a time a high profile project written in a lower level representation got ported to a higher level language. Software never gets rewritten in a higher level language, but software is constantly replaced by alternatives. First example that comes to mind is Discord, an Electron app that immediately and permanently killed every other voice client on the market when it launched.

I don't think the success of Discord is due to it being written in Electron. Or is it?

Re: A 10x Faster TypeScript

#349

Post by zerr »

butshouldyou wrote: post #231
zerr wrote: post #198

Use browser and web for websites, not applications. For apps, create native downloadable desktop software, which also work offline.

Funnily enough, that's exactly what they're doing in this announcement. They're rewriting `tsc` in Go and shipping native binaries, rather than shipping JS.

Didn't quite get, they compile ts to js using the compiler now written in Go, right? But we as end users still get js, not a native app.

Re: A 10x Faster TypeScript

#350

Post by gwbas1c »

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.

Thanks for answering questions.

One thing I'm curious about: What about updating the original Typescript-based compiler to target WASM and/or native code, without needing to run in a Javascript VM?

Was that considered? What would (at a high level) the obstacles be to achieving similar performance to Golang?

Edit: Clarified to show that I indicate updating the original compiler.

Post reply on HN