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

261–270 of 943 posts

Re: A 10x Faster TypeScript

#261

Post by zoogeny »

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.

Yes, scripting replacements often usurp existing ossified alternatives. And there is some truth that a higher level language gave some leverage to the developers. That is why I mentioned the advent of LLM based coding assistants and how this may level the playing field.

If we assume that coding assistants continue to improve as they have been and we also assume that they are able to generate lower level code on par with higher level code, then it seems the leverage shifts away from "easy to implement features" languages to "fast in most contexts" languages.

Only time will tell, of course. But I wonder if we will see a new wave of replacements from Electron based apps to LLM assisted native apps.

Re: A 10x Faster TypeScript

#262

Post by dleeftink »

noelwelsh wrote: post #237
Starlord2048 wrote: post #211

[flagged]

I don't think this is accurate. Javascript is not slow because of GC or JIT (the JVM is about twice as fast in benchmarks; Go has a GC) but because JS as a language is not designed for performance. Despite all the work that V8 does it cannot perform enough analysis to recover desirable performance. The simplest example to explain is the lack of machine numbers (e.g. ints). JS doesn't have any representation for this…

I think JS can really zoom if you let it. Hamsters.js, GPU.js, taichi.js, ndarray, arquero, S.js, are all solid foundations for doing things really efficiently. Sure, not 'native' performance or on the compile side, but having their computational models in mind can really let you work around the language's limitations.

Re: A 10x Faster TypeScript

#263

Post by pjmlp »

rvz wrote: post #249
Starlord2048 wrote: post #211

[flagged]

> When a language team abandons self-hosting (TS in TS) for raw performance (Go), it signals we've hit fundamental limits in JS/TS for systems programming. I hope you really mean for "userspace tools / programs" which is what these dev-tools are, and not in the area of device drivers, since that is where "systems programming" is more relevant. I don't know why one would choose JS or TS for "systems programming", but…

Back in my day, writing compilers was part of systems programming.

Re: A 10x Faster TypeScript

#264

Post by hedora »

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 be rewritten in C++/Rust after they fail to meet runtime performance / operability targets.

Wasn't there a recent study from Google that came to the same conclusion? (They see improved productivity for Go with junior programmers that don't understand static typing, but then they can never actually stabilize the resulting codebase.)

Re: A 10x Faster TypeScript

#265

Post by the_mitsuhiko »

Starlord2048 wrote: post #211

[flagged]

> The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day.

I'm not sure that this is particularly accurate for the Rust case. The goal of this project was to perform a 1:1 port from TypeScript to a faster language. The existing codebase assumes a garbage collector so Rust is not really a realistic option here. I would bet they picked GCed languages only.

Re: A 10x Faster TypeScript

#266

Post by SkiFire13 »

typ wrote: post #223
fabian2k wrote: post #94

Earlier quoted context omitted.

I find the discussion about the choice quite interesting, and many points are very convincing (like the GC one). But I am a bit confused about the comparison between Go and C#. Both should meet most of the criteria like GC, control over memory layout/allocation and good support for concurrency. I'm curious what the weaknesses of C# for this particular use case were that lead to the decision for Go.

C# is fine. But last I checked, the AOT compilation generates a bunch of .dll files, which are not suitable for a CLI program like Go's zero dependencies binary.

C# has an option to publish to a single self-contained file.

Re: A 10x Faster TypeScript

#267

Post by niederman »

christianqchung wrote: post #238
Starlord2048 wrote: post #211

[flagged]

This is not accusatory, but do you write your comments with AI? I checked your profile and someone else had the same question a few days ago. It's the persistent structure of "it isn't X – it's Y" with the em dash (– not -) that makes me wonder this. Nothing to add to your comment otherwise, sorry.

You know, some humans use the correct dash too...

Re: A 10x Faster TypeScript

#268

Post by ragnese »

dagw wrote: post #91
ragnese wrote: post #80

But, I was told that programming language choice doesn't matter and that I can write slow/bad code in any language... /s

You can write slow code in any language, but you cannot write fast code in any language.

I didn't include every variant I've ever read, but there have been no shortage of people saying that the only thing that matters is your algorithms.

Every time I've said that languages like Python, JavaScript, and basically any other language where it's hard to avoid heap allocations, pointer chasing, and copious data copies are all slow, there are plenty of people who come out of the woodwork to inform me that it's all negligible.

Re: A 10x Faster TypeScript

#269

Post by _benton »

noodletheworld wrote: post #51
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 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?

Golang is actually pretty easy to embed into JS/TS via wasm. See esbuild.

Re: A 10x Faster TypeScript

#270

Post by colonelspace »

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.

> Discord ... immediately and permanently killed every other voice client on the market

Do you mean voice clients like FaceTime, Zoom, Teams, and Slack?

Post reply on HN