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

661–670 of 943 posts

Re: A 10x Faster TypeScript

#661

Post by timeon »

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.

Sure but that comment was mostly about backend. If Discord used js/ts for backend they wouldn't replace anyone.

Re: A 10x Faster TypeScript

#662

Post by rattray »

DanRosenwasser wrote: post #165
bcherny wrote: post #5

Fast dev tools are awesome and I am glad the TS team is thinking deeply about dev experience, as always! One trade off is if the code for TS is no longer written in TS, that means the core team won’t be dogfooding TS day in and day out anymore, which might hurt devx in the long run. This is one of the failure modes that hurt Flow (written in OCaml), IMO. Curious how the team is thinking about this.

Hey bcherny! Yes, dog-fooding (self-hosting) has definitely been a huge part in making TypeScript's development experience as good as it is. The upside is the breadth of tests and infrastructure we've already put together to watch out for regressions. Still, to supplement this I think we will definitely be leaning a lot on developer feedback and will need to write more TypeScript that may not be in a compiler or lang…

Interesting! This sounds like a surprisingly hard problem to me, from what I've seen of other infra teams.

Does that mean more "support rotations" for TS compiler engineers on GitHub? Are there full-stack TS apps that the TS team owns that ownership can be spread around more? Will the TS team do more rotations onto other teams at MSFT?

Re: A 10x Faster TypeScript

#663

Post by pier25 »

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…

> It honestly has me questioning my default assumption to use JS runtimes on the server (e.g. Node, deno, bun).

The JS runtimes are fine for the majority of use cases but the ecosystem is really the issue IMO.

> the benefit of using the same code on the server/client has rarely if ever been a significant contributor to project maintainability for me

I agree and now with OpenAPI this is even less of an argument.

Re: A 10x Faster TypeScript

#664

Post by demurgos »

jillyboel wrote: post #635
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?

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

TypeScript compiles to JavaScript. It means both `tsc` and the TS program can share the same platform today.

With a TSC in Go, it's no longer true. Previously you only had to figure out how to run JS, now you have to figure out both how to manage a native process _and_ run the JS output.

This obviously matters less for situations where you have a clear separation between the build stage and runtime stage. Most people complaining here seem to be talking about environments were compilation is tightly integrated with the execution of the compiled JS.

Re: A 10x Faster TypeScript

#665

Post by xanth »

Chyzwar wrote: post #569
pjc50 wrote: post #17

Earlier quoted context omitted.

> Pity that they didn't go with AOT compiled .NET, though. Yeah. It seems to be unfashionable somewhat even within Microsoft. (edit: it seems to be you and me and barely anyone else on HN advocating for C#)

I think the main thing is that they are porting, not re-writing. Current tsc is functional by nature and that's makes go better fit.

I think the much larger ask C# couldn't answer is the "expressive" access to low level struct layout[1]

[1] https://www.youtube.com/watch?v=10qowKUW82U&t=769s

Re: A 10x Faster TypeScript

#666

Post by sethaurus »

jay_kyburz wrote: post #480
uticus wrote: post #453

Earlier quoted context omitted.

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…

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.

Re: A 10x Faster TypeScript

#668

Post by osigurdson »

jay_kyburz wrote: post #480
uticus wrote: post #453

Earlier quoted context omitted.

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…

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.

Go doesn't run in the browser however (except WASM but that is different).

Re: A 10x Faster TypeScript

#669

Post by ironmagma »

zoogeny wrote: post #649
ironmagma wrote: post #645

Earlier quoted context omitted.

Inevitably? Well, the promise of using something less efficient in terms of performance is that it will be more efficient in terms of development. Many times projects fail because they optimize too early and never built the features they needed to or couldn’t iterate fast enough to prove value and die. So if the native version is better but failed, it’s not so inevitable that it will get to that stage.

Right, which is my point about LLM code assistants. If you did have two cases in the past: native but slow to add features so the project eventually dies vs. scripted but performance is bad enough it eventually needs to be rewritten. (Of course, this is a false dichotomy but I'm playing into your scenario). Now we may have a new case: native but fast to add features using a code assist LLM. If that new case is a true…

That’s an interesting idea. It’s amazing how far we’ve come without essentially any objective data on how much these various methodologies (e.g. using a scripting language) improve or worsen development time.

The adoption of AI Code Assistance I am sure will be driven similarly anecdotally, because who has the time or money to actually measure productivity techniques when you can just build a personal set of superstitions that work for you (personally) and sell it? Or put another way, what manager actually would spend money on basic science?

Re: A 10x Faster TypeScript

#670

Post by sashank_1509 »

culi wrote: post #500
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.

> While we’re not yet feature-complete This is a big concern to me. Could you expand on what work is left to do for the native implementation of gsc? In particular, can you make an argument why that last bit of work won't reduce these 10x figures we're seeing? I'm worried the marketing got ahead of the engineering

It’s fine, if it’s 2x faster after being feature complete, I don’t really mind. It still is a free speedup to all existing code-bases. Developers don’t need to anything than install the latest version of TypeScript I presume
Post reply on HN