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

751–760 of 943 posts

Re: A 10x Faster TypeScript

#751

Post by Timon3 »

conartist6 wrote: post #658
moogly wrote: post #532

Earlier quoted context omitted.

> as someone who is fighting tooth and claw to keep JS language tooling in the JS ecosystem Have you considered the man-years and energy you're making everyone waste? Just as an example, I wonder what the carbon footprint of ESLint has been over the years... Now, it pales in comparison to Python, but still...

I'm no more thrilled than you at the cost of running ESLint, but using a high-level language doesn't need to mean being wasteful of resources. TS currently wastes tons of resources (most especially peoples' time) by not being able to share its data and infrastructure with other tools and ecosystems, but while there would be much bigger wins from tackling the systemic problem, you wouldn't be able to say something as…

If I could choose between Typescript speeding up 10x or all the surrounding tooling speeding up 20x, I'd take Typescript in a heartbeat. Slow type checking is the biggest pain point in my daily dev cycle.

Thank you Typescript team for chasing those promotions!

Re: A 10x Faster TypeScript

#752

Post by zozbot234 »

mappu wrote: post #601
zozbot234 wrote: post #592

Earlier quoted context omitted.

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.

I don't think Go supports any pointer arithmetic out-of-the-box? What it has in the base language is effectively references.

Re: A 10x Faster TypeScript

#753

Post by Cthulhu_ »

vacuity wrote: post #621
melbourne_mat wrote: post #530

Earlier quoted context omitted.

I think it's smart to start with a high level language which should reduce development time, prove the worth of the application, then switch to a lower level language later. What was that saying again? Premature optimisation is the root of all evil

https://news.ycombinator.com/item?id=29228427 A thread going into what Knuth meant by that quote that is usually shortened to "premature optimization is the root of all evil". Or, to rephrase it: don't tire yourself out climbing for the high fruit, but do not ignore the low-hanging fruit. But really I don't even see why "scripting languages" are the particular "high level" languages of choice. Compilers nowadays are…

I think (personal opinion / belief) Go hits that sweet spot; it's an "easy" language, but compiles down to a binary instead of e.g. Java, C#, JS etc.

Mind you I'm sure there were similar attempts at a language with those goals, but they didn't have the backing of Google.

Re: A 10x Faster TypeScript

#754

Post by neonsunset »

jujadjwdfs wrote: post #676

Not sure if this point was brought up but I think it's worth considering. If the Typescript team were to go with Rust or C# they would have to contend with async/await decoration and worry about starvation and monopolization. Go frees the developer from worrying about these concerns.

Go is more vulnerable to thread starvation when you go across interop. If you do not, it has better scheduling fairness but is less efficient at firing off new short-lived goroutines than .NET is at tasks.

Re: A 10x Faster TypeScript

#755

Post by Jean-Papoulos »

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…

>The main driver behind this project is that while Rust is very quick, the cost of serializing data between Rust and TypeScript is very high.

This sounds more like a "we're kinda stuck with Javascript here" situation. The team is making a compromise, can't have your cake and eat it too I guess.

Re: A 10x Faster TypeScript

#756

Post by ciarcode »

spankalee wrote: post #88
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.

Hey Daniel. I write a lot of tools that depend on the TypeScript compiler API, and they run in a lot of a lot of JS environments including Node and the browser. The current CJS codebase is even a little tricky to load into standard JS module supporting environments like browsers, so I've been _really_ looking forward to what Jake and others have said will be an upcoming standard modules based version. Is that still h…

I think they answered in their FAQ here: https://github.com/microsoft/typescript-go/discussions/455#d....

If I got it correctly, they created a node native module that allows synchronous communication on standard I/O between external processes.

So, this node module will make possible the communication between the typescript compiler GO process, that will expose an “API server compiler”, and a client side JavaScript process.

They don’t think it will be possible to port all APIs and some/most of them will be different than today.

Re: A 10x Faster TypeScript

#757

Post by zoogeny »

throwitaway1123 wrote: post #727
zoogeny wrote: post #716

Earlier quoted context omitted.

Ah, now we're at the dictionary definition level. So let's check Google: Inevitable: as is certain to happen; unavoidably. informal as one would expect; predictably. "inevitably, the phone started to ring just as we sat down" Which interpretation of the word is "good faith" considering the rest of my post? If I said "If you drink and drive you will inevitably get into an accident" - would you argue against that state…

I wrote 362 words on why language rewrites are a faulty indicator of language quality with multiple examples and anecdotes, and you hyper-fixated on the very first sentence of my comment, instead of addressing the substance of my claim. In what alternate universe is that a good faith argument? If you were truly arguing in good faith you'd restate your position in whichever way you'd like your argument represented, an…

You said: "Inevitable means impossible to evade. That's about as close to a black and white statement as possible."

I used Google to point out that your argument, which hinged on your definition of what the word "inevitable" means is the narrowest possible interpretation of my statement. An interpretation so narrow that it indicates you are arguing in bad faith, which I believe to be the case. You are accusing me of making an argument that I did not make by accusing me of not understanding what a word means. You are wrong on both accounts as demonstrated.

The only person thinking in black in white is the figment of me in your imagination. I've re-read the argument chain and I'm happy leaving my point where it is. I don't think your points, starting with your attempt at a counter example with Prisma, nor your exceptional compiler argument, nor any of the other points you have tried support your case.

Re: A 10x Faster TypeScript

#758

Post by DanielHB »

airforce1 wrote: post #433
nine_k wrote: post #380

Earlier quoted context omitted.

Would running WASM be any faster than running JS in V8?

In my experience it is pretty difficult to make WASM faster than JS unless your JS is really crappy and inefficient to begin with. LLVM-generated WASM is your best bet to surpass vanilla JS, but even then it's not a guarantee, especially when you add js interop overhead in. It sort of depends on the specific thing you are doing. I've found that as of 2025, Go's WASM generator isn't as good as LLVM and it has been ver…

I did some perf benchmarks a few years ago on some JS code vs C code compiled to WASM using clang and running on V8 vs the same C code compiled to x64 using clang.

The few cases that performed significantly better than the JS version (like >2x speed) were integer-heavy math and tail-call optimized recursive code, some cases were slower than the JS version.

What I was surprised was that the JS version had similar performance to the x64 version with -O3 in some of my benchmakrs (like float64 performance).

This was a while ago though when WASM support had just landed in browsers, so probably things got better now.

Re: A 10x Faster TypeScript

#759

Post by Yoric »

sethaurus wrote: post #739
Yoric wrote: post #296

Earlier quoted context omitted.

Yeah, the term has changed meaning several times. Early on, "systems programmer" meant basically what we call a "developer" now (by opposition to a programmer or a researcher).

At that time, what would have been the distinction between "programmer" and "developer"?

If my memory serves, the "programmer" was essentially a mathematician, working on a single algorithm, while a "system developer" was building an entire system around it.

Re: A 10x Faster TypeScript

#760

Post by Cthulhu_ »

xandrius wrote: post #348
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.

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

I do believe it's a factor; web apps have the most freedom when it comes to visual design (and the vast majority of developers for it), and it makes it a crossplatform application. Electron and web applications are the market leader in front-end / client side applications by a very wide margin. I mean I don't like it but that's how it is.
Post reply on HN