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

181–190 of 943 posts

Re: A 10x Faster TypeScript

#181

Post by legohead »

dimitropoulos wrote: post #19
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…

look, not to argue with a stranger on hacker news, lol, but genuine calm question here: is this really a helpful nit? I know what you're getting at but the blogpost itself doesn't imply that JavaScript is 10x faster. I could complain, about your suggested change, that it's really `build and typecheck` time. It's a title. Sometimes they don't have _all_ the context. That's ok.

misleading titles are a no-no on HN.

I agree with pseudopersonal in that the title should be changed. technically it's not misleading, but not everyone uses or is familiar with typescript.

Re: A 10x Faster TypeScript

#182

Post by zem »

fastball wrote: post #130
pseudopersonal wrote: post #60

Earlier quoted context omitted.

Thanks for the clarification. For those of us who don't use TypeScript day to day, I feel that it is ambigious. Without clicking the link, you wouldn't know if it's about a compiler or a runtime. What if they announced a bun competitor? https://betterstack.com/community/guides/scaling-nodejs/node... .

Those are javascript runtimes, not TypeScript runtimes. The point stands. If you don't know enough about TypeScript to understand that TypeScript is not a runtime, I'm not sure why you would care about TypeScript being faster (in either case).

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.

Re: A 10x Faster TypeScript

#183

Post by vessenes »

tyilo wrote: post #74
dimitropoulos wrote: post #2

yes, this will definitely vastly increase the Doom fps, haha (I’m the guy that did that project). But I think there’s a lot more to it than that. tl;dr — Rust would be great for a rewrite, but Go makes way more sense for a port. After the dust settles, I hope people focus on the outcomes, not the language choice. I was very surprised to see that the TypeScript team didn’t choose Rust, not just because it seemed like…

> Go and Rust are both memory safe. Go doesn't seem to be memory safe, see https://www.reddit.com/r/rust/comments/wbejky/comment/ii7ak8... and https://go.dev/play/p/3PBAfWkSue3

This is true in that if you pass pointers through go routines, you do not have guarantees about what’s at the end of that pointer. However, this is “by design” in that generally you shouldn’t do that; the overhead the go memory model places on developers is to remember what’s passed as value and what’s passed as a pointer, and act accordingly. The rest it takes care of for you.

The burden placed by rust on the developer is to keep track of all possible mutability and readability states and commit to them upfront during development. (If I may summarize, been a long time since I wrote any Rust). The rest it takes care of for you.

The question of which a developer prefers at a certain skill level, and which a manager of developers at a certain skill level prefers, is going to vary.

Re: A 10x Faster TypeScript

#184

Post by pbreit »

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.

Amazing!! I did not see timing. When might we see in VS Code? Edge?

Re: A 10x Faster TypeScript

#185

Post by surajrmal »

rat9988 wrote: post #109
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. I was trying ot push .net as our possible language for somehow high performance executables. Seeing this means I'll stop trying to advocate for it. If even this team doesn't believe in it.

They cited code style and porting as reasons to use go over c#, not performance.

Re: A 10x Faster TypeScript

#186

Post by dagw »

fabian2k wrote: post #155
dagw wrote: post #137

Earlier quoted context omitted.

Yea, sounds like cross platform AOT compiled C# not being mature and performant was a big reason that C# was rejected. One other thing I forgot to mention was that he talked about how the current compiler was mostly written as more or less pure functions operating on data structures, as opposed to being object oriented, and that this fits very well with the Go way of doing things, making 1:1 port much easier.

Immaturity of native AOT sounds like a likely culprit here. If they're after very fast startup times running classic C# is out. And native AOT is still pretty new. You can write pure functions operating on data structures in C#, it's maybe not as idiomatic as in Go, but it should not cause problems.

it's maybe not as idiomatic as in Go, but it should not cause problems.

Based on interviews, it seems Hejlsberg cares a lot about keeping the code base as idiomatic and approachable as possible. So it's clearly a factor.

Re: A 10x Faster TypeScript

#187

Post by localghost3000 »

Something that kind of got understated in here IMO is the improved refactoring and code intelligence that this will unlock. Very exciting! I am looking forward to all the new tooling and frameworks that come out of this change. TS is already an amazing language and just keeps getting better!

Re: A 10x Faster TypeScript

#188

Post by reactordev »

pjmlp wrote: post #149
Cthulhu_ wrote: post #144

Earlier quoted context omitted.

I'm not involved in the decisions, but don't C# applications have a higher startup time and memory usage? These are important considerations for a compiler like this that needs to start up and run fast in e.g. new CI/CD boxes. For a daemon like an LSP I reckon C# would've worked.

Native AOT exists, and C# has many C++ like capabilities, so not at all.

It exists but isn’t the same as a natively compiled binary. A lot gets packed into an AOT binary for it to work. Longer startup times, more memory, etc.

Re: A 10x Faster TypeScript

#189

Post by pzo »

kaoD wrote: post #10
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…

To clarify why it's actually not that ambiguous: TS is not (and does not have) a runtime at all. Even TS-first runtimes like Deno are (1) not TS but its own thing and most importantly (2) just JS engines with a frontend layer that treats TS as a first-class citizen (in Deno's case, V8). It's hard to tell if there will even be a runtime that somehow uses TS types to optimize even further (e.g. by proving that a functi…

there is static hermes from Meta that do AoT compilation to native so I find it actually ambiguous. For a second I thought they did a compiler instead of transpile r.
Post reply on HN