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

561–570 of 943 posts

Re: A 10x Faster TypeScript

#561

Post by zem »

timeflex wrote: post #468
zem wrote: post #182

Earlier quoted context omitted.

if typescript code execution got that much faster it might be a reason for someone to look into the language even if they knew nothing about it.

There are plenty of other reasons to consider TypeScript, but again, what code execution are referring to? The V8 JavaScript engine?

that's not the point I was making - gp was wondering why someone who didn't even know typescript compiled to javascript and ran atop a javascript engine would care that it had gotten 10x faster.

Re: A 10x Faster TypeScript

#564

Post by jchw »

steveklabnik wrote: post #497
jchw wrote: post #493

Earlier quoted context omitted.

Sure, that's all true. It does limit Go's memory safety guarantees. However, I still believe that just because Java and other languages can give better guarantees around the blast radius of concurrency bugs does not mean that Go's definition of memory safety is invalid. I believe you can justifiably call Go memory-safe with unsafe concurrency. This may give people the wrong idea about where exactly Go fits in on the…

> On the other hand, though, in practice, I've wound up using Go in production quite a lot, and these bugs are excessively rare. I both want to agree with this, but also point to things like https://www.uber.com/en-CA/blog/data-race-patterns-in-go/ , which found a bunch of bugs. They don't really contextualize it in terms of other kinds of bugs, so it's really hard to say from just this how rare they actually are. On…

The Uber page does a pretty good job of summing it up. The only thing I'd add is that there has been a little bit of effort to reduce footguns since they've posted this article; as one example, the issue with accidentally capturing range for variables is now fixed in the language[1]. On top of having a built-in (runtime) race detector since 1.1 and runtime concurrent map access detection since 1.6, Go is also adding more tools to make testing concurrent code easier, which should also help ensure potentially racy code is at least tested[2] (ideally, with the race detector on.) Accidentally capturing named return values is now caught by a popular linting tool[3]. There is also gVisor's checklocks analyzer, which, with the help of annotations, can catch many misuses of mutexes and data protected by mutexes[4]. (This would be a lot nicer as a language feature, but oh well.)

I don't know if I'd evangelize for adopting Go on the scale that Uber has: I think Go works best for shared-nothing architectures and gets gradually less compelling as you dig into more complex concurrency. That said, since Uber is an early adopter, there is a decent chance that what they have learned will help future organizations avoid repeating some of the same issues, via improvements to tooling and the language.

[1]: https://go.dev/blog/loopvar-preview

[2]: https://go.dev/blog/synctest

[3]: https://github.com/mgechev/revive/blob/HEAD/RULES_DESCRIPTIO...

[4]: https://pkg.go.dev/gvisor.dev/gvisor/tools/checklocks

Re: A 10x Faster TypeScript

#565

Post by pebal »

vips7L wrote: post #551
neonsunset wrote: post #504

Earlier quoted context omitted.

Chances are it was just personal preference of the team and decades of arguing about language design have worn out Anders Hejlsberg. I don't think structural typing alone is enough of an argument to justify the choice over Rust. Maybe the TS team thought choosing Go would have better optics. Well, they won't have it both ways because clearly this decision in my opinion is short-sighted and as someone aptly pointed on…

On the topic of preference, this thread has really shown me that there is a HUGE preference for a native-aot gc language that is _not_ Go. People want AOT because of the startup and memory characteristics, but do not want to sacrifice language ergonomics. C# could fill that gap if Microsoft would push it there.

Just use the fast GC library in C++.

Re: A 10x Faster TypeScript

#566

Post by nh2 »

AshleysBrain wrote: post #64
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.

Well-optimized JavaScript can get to within about 1.5x the performance of C++ - something we have experience with having developed a full game engine in JavaScript [1]. Why is the TypeScript team moving to an entirely different technology instead of working on optimizing the existing TS/JS codebase? [1] https://www.construct.net/en

Does "well-optimized JavaScript" mean "you can't use Objects"?

In JavaScript, you can't even put 8M keys in a Hashmap; inserts take > 1 second per element:

https://issues.chromium.org/issues/42202799

Re: A 10x Faster TypeScript

#567

Post by hansifer »

ggus wrote: post #451
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…

Agree. TypeScript is primarily a programming language. Did they make the language faster? No. Hence, the title is misleading.

That's debatable. I think most people that work with TS see it as a syntax extension for JS. Do you think JSX is a programming language?

Re: A 10x Faster TypeScript

#568

Post by hansifer »

Tadpole9181 wrote: post #334
wrs wrote: post #226

Earlier quoted context omitted.

Typescript is JavaScript at runtime. It’s not a separate language, just like Python with type annotations (TypePython?) is just Python at runtime. Both are just type annotations that get stripped away before anything tries to run the code. That’s the genius of the idea and why it’s so easily adopted.

It is quite literally a separate language. Python's type hints are a part of the Python specification and all valid Python type hints will run in any compliant Python runtime. Typescript is not, in any way, valid JavaScript. The moment you add any type syntax, you can no longer run the code in Node or Browsers without enabling a special preprocess step.

Do you think JSX is a separate language?

Re: A 10x Faster TypeScript

#569

Post by Chyzwar »

pjc50 wrote: post #17
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.

> Pity that they didn't go with AOT compiled .NET, though. Yeah. It seems to be unfashionable somewhat even within Microsoft. (edit: it seems to be you and me and barely anyone else on HN advocating for C#)

I think the main thing is that they are porting, not re-writing. Current tsc is functional by nature and that's makes go better fit.

Re: A 10x Faster TypeScript

#570

Post by smarx007 »

acomagu wrote: post #545
DanRosenwasser wrote: post #59

Earlier quoted context omitted.

We did anticipate this question, and we have actually written up an FAQ entry on our GitHub Discussions. I'll post the response below. https://github.com/microsoft/typescript-go/discussions/411 . ____ Language choice is always a hot topic! We extensively evaluated many language options, both recently and in prior investigations. We also considered hybrid approaches where certain components could be written in a nativ…

Personally, I want to know why Go was chosen instead of Zig. I think Zig is really more WASM-friendly than Go, and it's much more similar to JavaScript than Rust is. Memory management? Or a stricter type system?

For being production-ready?
Post reply on HN