To all reasonable software developers out there, please don't listen to the prevailing groupthink. Javascript (the language) has many semantic problems but speed (from the VM) is one of it's best features! Like, you have to be writing some questionable code in very questionable styles/dialects to have a 10x (or more!) slowdown vs native.
Obviously - using native non-portable language/compiler features - you can reach some worthwhile speedup for certain workloads. But I have yet to see any of these "we rewrote our build system to Rust" type blog posts utilize any them.
It's always the apples-to-oranges marketing style drivel. Just because the some assertion comes from a very (very!) large company or well-known community member doesn't mean it is true.
In all my years of lurking this site, this port mortem is one of the few articles on this topic I trust:
<a href="https://zaplib.com/docs/blog_post_mortem.html" rel="nofollow">https://zaplib.com/docs/blog_post_mortem.html
This argument can also be applied to the separate, startup time performance axis. Though there are more tradeoffs there.
As someone who is creating a serious programming language whose bootstrap compiler is currently in (a restricted form) of JS. I am immensely skeptical of their claim on all fronts.
Why are you skeptical of Anders Hejlsberg's claims about his own language? He designed TypeScript.
Are you claiming that your own, separate programming language is faster than TypeScript, just like Go is faster than TypeScript? So in fact you agree with Anders?
Yes, much faster. Conversely, I don't think Anders is claiming his Typescript implementation to be particularly fast - he believed JS wasn't fast enough to solve his performance problems. Which isn't true.
The TS compiler has always been slow. There are/were several TS-in-Rust/Go compilers long before Anders announced and released the offical Go version. I've also been writing transpilers since before TS was a thing, the TS team could have made it work in JS.
But it's often easier to switch to a language that gives you that structure/performance for free. "Free" in that large companies have the budget to afford a bug-for-bug port/rewrite.
Yes, only in that it's often easier to just rewrite it in a lower level language and be done. No, if you consider the time and effort for a bug-for-bug port.
They could have rewritten the Typescript compiler in better Typescript. I just peeked at random files in last TS compiler branch before the port (v6.0.3). Simply put, I would not have written it that way. That style would surely hit it performance cliffs.
If anyone from the TS team is lurking, I can be paid a reasonable consulting fee to talk lol. No free work from me, I'm already too busy with my own language.
Or contract me to match (or maybe even exceed) the Go port.
But I suspect Anders and the TS team are plenty satisfied with their Go port. So maybe, it'll be more of an educational adventure.
suplexer · · focus · HN ↗
Obviously - using native non-portable language/compiler features - you can reach some worthwhile speedup for certain workloads. But I have yet to see any of these "we rewrote our build system to Rust" type blog posts utilize any them.
It's always the apples-to-oranges marketing style drivel. Just because the some assertion comes from a very (very!) large company or well-known community member doesn't mean it is true.
In all my years of lurking this site, this port mortem is one of the few articles on this topic I trust: <a href="https://zaplib.com/docs/blog_post_mortem.html" rel="nofollow">https://zaplib.com/docs/blog_post_mortem.html
This argument can also be applied to the separate, startup time performance axis. Though there are more tradeoffs there.
cisc · · focus · HN ↗
<a href="https://devblogs.microsoft.com/typescript/typescript-native-port/" rel="nofollow">https://devblogs.microsoft.com/typescript/typescript-native-...
suplexer · · focus · HN ↗
cisc · · focus · HN ↗
Are you claiming that your own, separate programming language is faster than TypeScript, just like Go is faster than TypeScript? So in fact you agree with Anders?
suplexer · · focus · HN ↗
The TS compiler has always been slow. There are/were several TS-in-Rust/Go compilers long before Anders announced and released the offical Go version. I've also been writing transpilers since before TS was a thing, the TS team could have made it work in JS.
But it's often easier to switch to a language that gives you that structure/performance for free. "Free" in that large companies have the budget to afford a bug-for-bug port/rewrite.
cisc · · focus · HN ↗
suplexer · · focus · HN ↗
They could have rewritten the Typescript compiler in better Typescript. I just peeked at random files in last TS compiler branch before the port (v6.0.3). Simply put, I would not have written it that way. That style would surely hit it performance cliffs.
If anyone from the TS team is lurking, I can be paid a reasonable consulting fee to talk lol. No free work from me, I'm already too busy with my own language.
Or contract me to match (or maybe even exceed) the Go port.
But I suspect Anders and the TS team are plenty satisfied with their Go port. So maybe, it'll be more of an educational adventure.