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

701–710 of 943 posts

Re: A 10x Faster TypeScript

#701

Post by _bin_ »

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 don't think this speaks to the general reasons someone would rewrite a mid- or low-level project in a high-level language, so much as to the special treatment JS/TS get. yes, your data model being the default supported, and everything else in the world having to serialize/deserialize to accommodate that, slows performance. in other words, this is just a reason to use the natively-supported JS/TS, still very much the favorite children of browser engines, over the still sort of hacked-in Rust.

Re: A 10x Faster TypeScript

#703

Post by _bin_ »

electroly wrote: post #21

I wonder, for a Microsoft project, why not C#? Would have been a nice win for the home team.

same reason i hate gradle/maven/ant: shipping a big runtime that many devs won't have installed for a build tool is bad. even with AOT, you still need a dotnet runtime.

Re: A 10x Faster TypeScript

#704

Post by throwitaway1123 »

zoogeny wrote: post #699
throwitaway1123 wrote: post #671

Earlier quoted context omitted.

Rather than fixating on this single Prisma example, I'd like to address your larger point which seems to be that all greenfield projects are necessarily best suited to low level languages. First of all, I would argue that software rewrites are a bad proxy metric for language quality in general. Language rewrites don't measure languages purely on a qualitative scale, but rather on a scale of how likely they are to be…

> your larger point which seems to be that all greenfield projects are necessarily best suited to low level language That is not my intention. Perhaps you are reading absolutes and chasing after black and white statements. When I say "it makes me think I should ..." I am not saying: "Everyone everywhere should always under any circumstances ...". It is a call to question the assumption, not to make emphatic universal…

> That is not my intention. Perhaps you are reading absolutes and chasing after black and white statements.

The first comment I wrote in this thread was a response to the following quote: "Yet projects inevitably get to the stage where a more native representation wins out." Inevitable means impossible to evade. That's about as close to a black and white statement as possible. You're also completely ignoring the substance of my argument and focusing on the wording. My point is that language rewrites (like the TS rewrite that sparked this discussion) are a faulty indicator of scripting language quality.

> I almost think you aren't reading my post at this point and are just arguing with a strawman you invented in your head. But I am assuming good faith on your part here, so once again I'll just repeat myself again and again: LLMs have already changed the barrier to entry for low-level languages and they will continue to do so.

And I've already said that I disagree with this assertion. I'll just quote myself in case you haven't read through all my comments: "I'm not an AI pessimist, but I'm also not an AI maximalist who is convinced that AI will completely eliminate the need for human code authoring and review, and as long as humans are required to write and review code, then those benefits [of scripting languages] still apply." I was under the impression that I didn't have to keep restating my position.

I don't believe that AI has eroded the barriers of entry to the point where the average Ruby or PHP developer will enjoy passing around memory allocators in Zig while writing API endpoints. Neither of us can be 100% certain about what the future holds for AI, but as someone else pointed out, making technical decisions in the present based on AI speculation is a gamble.

Re: A 10x Faster TypeScript

#705

Post by campers »

zestyping wrote: post #643

That's a pretty misleading clickbait title. TypeScript isn't getting 10x faster; the TypeScript compiler is getting 10x faster. I would argue it needs editing, as it violates the HN guideline: > use the original title, unless it is misleading or linkbait; don't editorialize.

There isn't a TypeScript runtime, it is just a JavaScript/ECMAScript compiler/transpiler with a type checking and language server

Re: A 10x Faster TypeScript

#706

Post by nindalf »

sapiogram wrote: post #407
never_inline wrote: post #339

Earlier quoted context omitted.

This is definitely AI, repetitive and reads in style of a marketing copy / sensational report.

They're not "definitely" an AI. Sounds like a normal Go enthusiast to me.

A Go enthusiast who’s never heard of esbuild? Not impossible, but unlikely.

Re: A 10x Faster TypeScript

#707

Post by nimchimpsky »

cryptonector wrote: post #681
electroly wrote: post #143

Earlier quoted context omitted.

This is a great response but this is "why is Go better than JavaScript?" whereas my question is "why is Go better than C# , given that C# was famously created by the guy writing the blog post and Go is a language from a competitor?" C# and TypeScript are Hejlsberg's children; C# is such an obvious pick that there must have been a monster problem with it that they didn't think could ever be fixed. C# has all that stuf…

GP's answer is a great answer to why Go instead of Rust , which u/no_wizard asked about. And the answer to that boils down to the need to traverse data structures in ways which Rust makes difficult, and the simplicity of a GC.

[dead]

Re: A 10x Faster TypeScript

#708

Post by sublinear »

Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?

Re: A 10x Faster TypeScript

#709

Post by PartiallyTyped »

dist1ll wrote: post #431
jjice wrote: post #31

Earlier quoted context omitted.

If I recall in an article from a while back, the idea was originally rust, but the current compiler design had lots of references shared references that would make the port to rust a lot of work.

Dealing with references you typically find in a compiler is not a problem for Rust. Arena allocation and indices are your friend.

Flattened asts are also faster than tree/pointer asts.

Re: A 10x Faster TypeScript

#710

Post by danielheath »

sublinear wrote: post #708

Typescript compiles to javascript, so does this not prove what people have been screaming from the rooftops for so long that there's a significant performance penalty with typescript for almost no actual benefit?

> a significant performance penalty with typescript

There's a significant performance penalty for using javascript outside the browser.

I'm not aware of any JS runtime outside a browser that supports concurrency (other than concurrently awaiting IO), so you can't do parallel compilation in a single process.

It's generally also very difficult to make a JS program as fast as even a naive go program, and the performance tooling for go is dramatically more mature.

Post reply on HN