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

311–320 of 943 posts

Re: A 10x Faster TypeScript

#311

Post by madeofpalk »

dimgl wrote: post #145
bitwize wrote: post #120

Earlier quoted context omitted.

.NET has AOT compilation now. There really is no excuse, especially when you consider that C# has a pretty decent type system and Go has an ad-hoc, informally specified, bug-ridden, slow implementation of half of a decent type system.

> Go has an ad-hoc, informally specified, bug-ridden, slow implementation of half of a decent type system. It's not lost on me that this is a widely used aphorism. The problem is that it's not true in any way shape or form.

People using pointers when they want to hack in null values points towards a problem in Go's type system.

Re: A 10x Faster TypeScript

#312

Post by TechSquidTV »

pseudopersonal wrote: post #8

The post title is a bit misleading. It should say a 10x faster build time, or a 10x faster TypeScript compiler . tsc (compiler) is 10x faster, but not the final TS program runtime. Still an amazing feat! But doom will not run faster "To meet those goals, we’ve begun work on a native port of the TypeScript compiler and tools. The native implementation will drastically improve editor startup, reduce most build times by…

Since you don't execute TypeScript, and TS never has anything to do with the end resulting app, I don't think it was misleading at all.

Re: A 10x Faster TypeScript

#313

Post by gavmor »

garbagepatch wrote: post #290

What do they mean by improving editor startup time? Does the editor (I assume vscode?) run the compiler as part of the startup? Why?

There are various ways to (de)couple the compiler to/from vscode, but it's definitely handy to have inline typechecking. Is this possible without running the compiler?

Re: A 10x Faster TypeScript

#314

Post by dleeftink »

jsheard wrote: post #298
dleeftink wrote: post #262

Earlier quoted context omitted.

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.

JS can be pretty fast if you let it, but the problem is the fastest path is extremely unergonomic. If you always take the fastest possible path you end up more or less writing asm.js by hand, or a worse version of C that doesn't even have proper structs.

I find these userland libraries particularly effective, because you'll never leave JS land, conveniently abstracting over Workers, WebGL/WebGPU and WASM.

Re: A 10x Faster TypeScript

#315

Post by gwbas1c »

register wrote: post #227
Starlord2048 wrote: post #211

[flagged]

I don't see why Go deployment model is superior to C#. You can easily build native binaries in C# as well nowadays.

I get the impression that, because Go has a lot of similar semantics to Typescript, it was easier to port to Go than other languages.

From https://github.com/microsoft/typescript-go/discussions/411

> Idiomatic Go strongly resembles the existing coding patterns of the TypeScript codebase, which makes this porting effort much more tractable.

> We also have an unusually large amount of graph processing, specifically traversing trees in both upward and downward walks involving polymorphic nodes. Go does an excellent job of making this ergonomic, especially in the context of needing to resemble the JavaScript version of the code.

Personally, I'm a big believer in choosing the right language for the job. C# is a great language, and often is "good enough" for many jobs. (I've done it for 20 years.) That doesn't mean it's always the best choice for the job. Likewise, sometimes picking a "familiar language" for a target audience is better than picking a personal favorite.

Re: A 10x Faster TypeScript

#316

Post by bichiliad »

pjmlp wrote: post #12

Even though I have my considerations regarding Go, I love that they picked Go instead of the fashion to go Rust that seems to be the norm now. A compiled managed language is much better approach for userspace applications. Pity that they didn't go with AOT compiled .NET, though.

There are some external projects that have tried to port tsc to native. stc[0], for instance, was one. Iirc it started out in Go since it had a more comparable type system (they both use duck typing) making it easier to do one-to-one conversions of code from one language to the other. I’m not totally sure why it ended up pivoting to rust.

[0]: https://github.com/dudykr/stc

Re: A 10x Faster TypeScript

#317

Post by [deleted] »

vessenes wrote: post #163
pjmlp wrote: post #84

Earlier quoted context omitted.

Thanks, but it really doesn't clarify why a team with roots on the .NET ecosystem decided C#/Native AOT isn't fit for purpose.

Pure speculation, but C# is not nearly the first class citizen that go binaries are when you look at all possible deployment targets. The “new” Microsoft likely has some built-in bias against “embrace and extend” architectural and business decisions for developers. Overall this doesn’t seem like a hard choice to me. Cue rust devotees in 3, 2, ..

[deleted]

Re: A 10x Faster TypeScript

#318

Post by gwbas1c »

abdusco wrote: post #257
register wrote: post #227

Earlier quoted context omitted.

I don't see why Go deployment model is superior to C#. You can easily build native binaries in C# as well nowadays.

Smaller binary sizes for easier + cheaper distribution might be a factor.

You can make very small binaries in C# if you want to.

But, the team posted their rationale for Go here: https://github.com/microsoft/typescript-go/discussions/411

Re: A 10x Faster TypeScript

#320

Post by throwitaway1123 »

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 by the Go TypeScript port to non-compiler use cases. A compiler is perhaps the worst use case for a language like JS, because it is both (as Anders Hejlsberg refers to it) an "embarassingly parallel task" (because each source file can be parsed independently), but also requires the results of the parsing step to be aggregated and shared across multiple threads (which requires shared memory multithreading of AST objects). Over half of the performance gains can be attributed to being able to spin up a separate goroutine to parse each source file. Anders explains it perfectly here: https://www.youtube.com/watch?v=ZlGza4oIleY&t=2027s

We might eventually get shared memory multithreading (beyond Array Buffers) in JS via the Structs proposal [1], but that remains to be seen.

[1] https://github.com/tc39/proposal-structs?tab=readme-ov-file

Post reply on HN