Curious how this is going to affect Cursor - I'm assuming it'll just be a drop-in replacement and we can expect Cursor to get the same speed-up as VSCode.
A 10x Faster TypeScript
301–310 of 943 posts
Re: A 10x Faster TypeScript
#302Earlier quoted context omitted.
Well-optimized JavaScript can, if you jump through hoops like avoiding object creation and storing your data in `Uint8Array`s. But idiomatic, maintainable JS simply can't (except in microbenchmarks where allocations and memory layout aren't yet concerns). In a game engine, you probably aren't recreating every game object from frame to frame. But in a compiler, you're creating new objects for every file you parse. Tha…
I'd say that our JS game engine codebase is generally idiomatic, maintainable JS. We don't really do anything too esoteric to get maximum performance - modern JS engines are phenomenal at optimizing idiomatic code. The best JS performance advice is to basically treat it like a statically typed language (no dynamically-shaped objects etc) - and TS takes care of that for you. I suppose a compiler is a very different us…
Note that games are based on main loops + events, for which JITs are optimized, while compilers are typically single run-to-completion, for which JITs aren't.
So this might be a very different performance profile.
*edit* I had initially written "single-pass", but in the context of a compiler, that's ambiguous.
Re: A 10x Faster TypeScript
#303Earlier quoted context omitted.
I wish there was a language like rust without the borrow checking and lifetimes that was also popular and lives in the same area as go. Because I think go is actually the best language in this category but it’s only the best because there is nothing else. All in all golang is not an elegant language.
It’s not popular compared to Go/Rust, but many find Nim scratches that itch: https://nim-lang.org/
Zig is another popular neo-language in the same rough space.
Re: A 10x Faster TypeScript
#304Even 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.
One unrelated team at Microsoft doesn't 'believe' in .NET is enough to make you change direction?
Re: A 10x Faster TypeScript
#305Earlier quoted context omitted.
What is the forward paths available for efforts like the TS Playground under Typescript 7 (native)? One of the nice advantages of js is that it can run so many places. Will TypeScript still be able to enjoy that legacy going forward, or is native only what we should expect in 7+?
We anticipate that we will eventually get a playground working on the new native codebase. We know we'll likely compile down to WebAssembly, but a lot of how it gets integrated will depend on what the API looks like. We're currently giving a lot of thought to that, but we have good ideas. https://github.com/microsoft/typescript-go/discussions/455
Will this be a prerequisite of the 7.0 release?
Re: A 10x Faster TypeScript
#306Earlier quoted context omitted.
This is shockingly out-of-date statement by Anders. I'm not sure what's going on, I guess he's just not involved with the runtime side of .NET at all to actually know where the capability sits circa 2024/2025. But really, it's a terrible situation to be in. Especially just how worse langdev UX in Go is compared to C#, F# or Rust. No one would've batted an eye if either of those was used.
> Especially just how worse langdev UX in Go is compared to C#, F# or Rust. Can you explain why the DX in Go is "worse"? I've seen the exact opposite during my professional work.
Lack of optionals/enum/sum types is a huge regression from Typescript to go IMHO.
Re: A 10x Faster TypeScript
#307I'm really surprised by this visceral reaction to not choosing Rust. Go is a great language and I'd choose it for a majority of projects over Rust just based off of the simplicity of the language and the ability to spin up developers on it quickly. Microsoft is a big corporation. Why _not_ use Go?
> Why _not_ use Go? Because of its truly primitive type system, and because Microsoft already has a much better language — C#, which is both faster and can be more high level and more low-level at the same time, depending on your needs. I am a complete nobody to argue with the likes of Hejlsberg, but it feels like AOT performance problems could be solved if tsc needed it, and tsc adoption of C# would also help push C…
I'm inclined to trust the judgement of Hejlsberg, the chief architect of C#, in this matter.
Re: A 10x Faster TypeScript
#308Earlier quoted context omitted.
There is an interview with Anders Hejlsberg here: https://www.youtube.com/watch?v=ZlGza4oIleY The question comes up and he quickly glosses over it, but by the sound of it he isn't impressed with the performance or support of AOT compiled C# on all targeted platforms.
he went into more detail about C# in this one: https://youtu.be/10qowKUW82U?t=1154s
He says:
- C# Ahead of Time compiler doesn't target all the platforms they want.
- C# Ahead of Time compiler hasn't been stressed in production as many years as Go.
- The core TypeScript compiler doesn't use any classes; Go is functions and datastructures whereas C# is heavily OOP, so they would have to switch paradigms to use C#.
- Go has better control of low level memory layouts.
- Go was ultimately the path of least resistance.
Re: A 10x Faster TypeScript
#309Earlier quoted context omitted.
I find the discussion about the choice quite interesting, and many points are very convincing (like the GC one). But I am a bit confused about the comparison between Go and C#. Both should meet most of the criteria like GC, control over memory layout/allocation and good support for concurrency. I'm curious what the weaknesses of C# for this particular use case were that lead to the decision for Go.
C# is fine. But last I checked, the AOT compilation generates a bunch of .dll files, which are not suitable for a CLI program like Go's zero dependencies binary.
C# can create single-binary executables, even without native AOT.
Re: A 10x Faster TypeScript
#310Earlier quoted context omitted.
I don't think c or rust are really 'closer to the metal' than golang (what they're using)
Considering Go is the only language with a garbage collector out of the three languages you mentioned, I'm not sure how you reach the conclusion they're all as close to the metal. C and Rust both have predictable memory behaviour, Go does not.
Go isn't that bad in terms of memory predictability to be honest. It generally has roughly 100% overhead in terms of memory usage compared to no GC. This can be reduced by using GOGC env variable, at the cost of worse performance if not careful.