One question I'm surprised isn't discussed here is how much AI code generation was used in this port. It seems like the perfect use case for it.
A 10x Faster TypeScript
351–360 of 943 posts
Re: A 10x Faster TypeScript
#352Earlier 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…
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…
> "given that C# was famously created by the guy writing the blog post"
What is this logic? "You worked on C# years ago so you must use C# for everything"?
"You must dictate C# to every team you lead forever, no matter what skills they have"?
"You must uphold a dogma that C# is the best language for everything, because you touched it last"?
Why aren't you using this logic to argue that they should use Delphi or TurboPascal because Anders Hejlsberg created those? Because there is no logic; the person who created hammers doesn't have to use hammers to solve every problem.
Re: A 10x Faster TypeScript
#353Earlier 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.
> sounds like cross platform AOT compiled C# not being mature and performant was a big reason I don't think it was the performance. C# is usually on par or faster than Go. Could be the lack of maturity but also that I believe Go produces smaller binaries which makes a lot of sense for a CLI.
I never heard C# being fasted than Go, except on certain batched jobs and even there Go can be better.
Re: A 10x Faster TypeScript
#354Earlier quoted context omitted.
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
Our best estimate for how much faster the Go code is (in this situation) than the equivalent TS is ~3.5x In a situation like a game engine I think 1.5x is reasonable, but TS has a huge amount of polymorphic data reading that defeats a lot of the optimizations in JS engines that get you to monomorphic property access speeds. If JS engines were better at monomorphizing access to common subtypes across different map sha…
I used to work on compilers & JITs, and 100% this — polymorphic calls is the killer of JIT performance, which is why something native is preferable to something that JIT compiles.
Also for command-line tools, the JIT warmup time can be pretty significant, adding a lot to overall command-to-result latency (and in some cases even wiping out the JIT performance entirely!)
Re: A 10x Faster TypeScript
#355People seem very hurt that the creator of C# didn't pick C# for this very public project from a multi-trillion-dollar corp. I find it very refreshing, they defined logical requirements for what they wanted to do and chose Golang because it ticked more boxes than C#. This doesn't mean that C# sucks or that every C# project should switch to Golang, but there seems to be a very vocal minority affected by this logical de…
My favorite benefit of Go over C# is that I don’t have to carry around a dotnet runtime to every service that touches my Typescript code.
Re: A 10x Faster TypeScript
#356I can see why they didn't use Rust, I've written little languages in that myself, so I know what is involved, even though I like the language a lot. But I'm quite surprised they didn't use C#. I would have thought ahead-of-time optimized C# would give nearly the same compilation speed as Go. They do seem to be leaning into concurrency a lot so maybe its more about Go's implementation of that (CSP-like), but doesn't .Net have a near-equivalent to that? Have not used it in a while.
Also I get the sense from the video that it still outputs only JS. It would be nice if we could build typescript executables that didn't require that, even if was just WASM, though that is more of a different backend rather than a different compiler.
Edit: C# was addressed: https://github.com/microsoft/typescript-go/discussions/411#d...
Re: A 10x Faster TypeScript
#357[flagged]
> The Go choice over Rust/C# reveals something deeper: Microsoft prioritized shipping a working solution over language politics. Go's simplicity (compared to Rust) and deployment model (compared to C#) won the day. I'm not sure that this is particularly accurate for the Rust case. The goal of this project was to perform a 1:1 port from TypeScript to a faster language. The existing codebase assumes a garbage collector…
Also explained in the FAQ: https://github.com/microsoft/typescript-go/discussions/411
Re: A 10x Faster TypeScript
#358[flagged]
I don't think this is accurate. Javascript is not slow because of GC or JIT (the JVM is about twice as fast in benchmarks; Go has a GC) but because JS as a language is not designed for performance. Despite all the work that V8 does it cannot perform enough analysis to recover desirable performance. The simplest example to explain is the lack of machine numbers (e.g. ints). JS doesn't have any representation for this…
JS, interestingly, has a notion of integers, but only in the form of integer arrays, like Int16Array.
I wonder if Typescript could introduce integer type(s) that a direct TS -> native code compiler (JIT or AOT) could use. Since TS becomes valid JS if all type annotations are removed, such numbers would just become normal JS numbers from the POV of a JS runtime which does not understand TS.
Re: A 10x Faster TypeScript
#359Earlier quoted context omitted.
You can write slow code in any language, but you cannot write fast code in any language.
I didn't include every variant I've ever read, but there have been no shortage of people saying that the only thing that matters is your algorithms. Every time I've said that languages like Python, JavaScript, and basically any other language where it's hard to avoid heap allocations, pointer chasing, and copious data copies are all slow, there are plenty of people who come out of the woodwork to inform me that it's…
no shortage of people saying that the only thing that matters is your algorithms.
To be a little bit fair to those people, I have been in many situations where people go "my matlab/python code is too slow, I must re-write it in C", and I've been able to get an order of magnitude improvement by re-writing the code in the same language. Hell I've ported terrible Fortran code to python/numpy and gotten significant performance improvement. Of course taking that well written code and re-writing that in well written C will probably give you a further order of magnitude improvement. Fast code in a slow language can beat slow code in a fast language, but obviously never beat fast code in a fast language.
Re: A 10x Faster TypeScript
#360Earlier 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…
It’s a political anti-benefit in most of the open-source world. And C# is not considered a high quality runtime once you leave Windows.
> And C# is not considered a high quality runtime once you leave Windows.
By who?