6 ms·

Microsoft rewriting typescript tools in Go and getting a 10x speedup? It's wild that they would choose Go for that. And a surprising level of speedup. https:/

Microsoft rewriting typescript tools in Go and getting a 10x speedup? It's wild that they would choose Go for that. And a surprising level of speedup. https://devblogs.microsoft.com/typescript/typescript-native-port/ https://devblogs.microsoft.com/typescript/typescript-native-...

tapirl 1y ago
My surprise is typescipt is so slow. I have never used it yet, but I think will never too.
- tgma 1y ago
  I suspect the particular use-case of parsing/compiling is pathologically bad for JavaScript runtimes. That said, they are still leaps faster than reference Python and Ruby interpreters.
  - deleted 1y ago
    [deleted]
- antonvs 1y ago
  Technically Typescript can't really be slow, since it's just a preprocessor for Javascript, and the speed of its programs will depend on which Javascript implementation you use. Typescript's sweet spot is making existing Javascript codebases more manageable. It can also be fine in I/O-heavy scenarios where Javascript's async model allows it to perform well despite not having the raw execution performance of lower-level languages.
  - capitol_ 1y ago
    I thought that (for example) deno executed typescript natively?
    - wiseowise 1y ago
      It executes typescript without you compiling it to JavaScript first, it doesn’t make code execution any faster.
- IshKebab 1y ago
  Depends what you mean by slow. The Typescript code was 3x slower than the Go code, and a 3x overhead is pretty much the best you can do for a dynamically typed language. Languages like Python and Ruby are much much slower than that (CPython is easily 10x slower than V8) and people don't seem to care.
- EMM_386 1y ago
  At the risk of feeling silly for not knowing this ... why is TypeScript considered a programming language, and how can you make it "faster"? I have used its it came out so I do know what it is, but I have people ask if they should write their new program in TypeScript, thinking this is something they can write it in and then run it. My usage of it is limited to JavaScript, so I see it as adding a static typing layer to JavaScript, so that development is easier and more logical, and this typing information is stripped out when transpiled, resulting in pure JavaScript which is all the browser understands. The industry calls it a programming language, so I do too just because this is not some semantic battle I want to get into. But in my mind it's not. There's probably a word for what it is, I just can't think of it. Type system? And I don't understand a "10x speedup" on TypeScript, because it doesn't execute. I can understand language services for things like VS Code that handle the TypeScript types getting 10x faster, but not TypeScript itself. I assume that is what they are talking about in most cases. But if this logic isn't right, let me know.
  - flohofwoe 1y ago
    The "10x speedup" is for the compilation step from TS to JS, eg how much faster the new Typescript compiler is, not the runtime performance of the JS output. Theoretically(!) using TS over JS may indirectly result in slightly better perf though because it nudges you towards not mutating the shape of runtime objects (which may cause the JS engine to re-JIT your code). The extra compilation step might also allow to do some source-level optimizations, like constant folding. But I think TS doesn't do this (other JS minifiers/optimizers do though).
tgma 1y ago
In my experience, Go is one of the best LLM targets due to simplicity of the language (no complex reasoning in the type system or borrow checker), a high quality, unified, and language-integrated dependency ecosystem[1] for which source is available, and vast training data. [1]: Specifically, Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consistency of dependencies across time.
- weinzierl 1y ago
  AFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
  - deleted 1y ago
    [deleted]
  - tgma 1y ago
    Not that much different than a type checker in any language (arguably it is the same thing). I have been using various LLMs extensively with Rust. It's not just borrow checker. The dependencies are ever-changing too. Go and Python seem to be the RISC of LLM targets. Comparatively, the most problematic thing about generated Go code is the requirement of using every imported package and declared symbol.
  - steveklabnik 1y ago
    The borrow checker does not change behavior, so any correct program will be fine without borrow checking. The job of borrow checking is to reject programs only. mrustc also does not implement a borrow checker.
- KRAKRISMOTT 1y ago
  Well it certainly makes error handling easy. No need to reason about complex global exception handlers and non-linear control structures. If you see an error, return it as a value and eventually it will bubble up. If err != nil is verbose but it makes LLMs and type checkers happy.
wiseowise 1y ago
A tooling team selects language widely used in tooling circles - wild, shocking.
lelanthran 1y ago
> And a surprising level of speedup. Not surprising at all; I keep pointing out that the language benchmarking game is rarely, if at all, reflective of real-world usage. Any time you point out how slow JS is someone always jumps up with a link to some benchmark showing that it is only 2x slower than Go (or Java, or whatever). The benchmarks game, especially in GC'ed languages, are not at all indicative of real-world usage of the language. Real world usage (i.e. idiomatic usage) of language $FOO is substantially different from the code written for the benchmarks games.
- igouy 1y ago
  Perhaps "real-world usage" is "… rarely, if at all, reflective of [other] real-world usage …". Perhaps when you write "idiomatic usage" you mean un-optimized.
dgb23 1y ago
It doesn't surprise me at all. Idiomatic Go leans on value types, simple loops and conditionals, gives you just enough tools to avoid unnecessary allocations, doesn't default to passing around pointers for everything, gives you more control over memory layout. JS runtimes have to do a lot of work in order to spit out efficient code. It also requires more specialized knowledge from programmers to write fast JS. I think esbuild and hugo are two programs that showcase this pretty well. Esbuild specifically made a splash in the JS world.
kristianp 1y ago
Here's the FAQs, where they explain the decision to go with Go and not, say, rust. https://github.com/microsoft/typescript-go/discussions/categories/faqs https://github.com/microsoft/typescript-go/discussions/categ... Hejlsberg also says in this video, about 3.3x performance is from going native and the other 2-3x is by using multithreading. https://www.youtube.com/watch?v=pNlq-EVld70&t=51s https://www.youtube.com/watch?v=pNlq-EVld70&t=51s

tapirl 1y ago

My surprise is typescipt is so slow. I have never used it yet, but I think will never too.

tgma 1y ago
I suspect the particular use-case of parsing/compiling is pathologically bad for JavaScript runtimes. That said, they are still leaps faster than reference Python and Ruby interpreters.
- deleted 1y ago
  [deleted]
antonvs 1y ago
Technically Typescript can't really be slow, since it's just a preprocessor for Javascript, and the speed of its programs will depend on which Javascript implementation you use. Typescript's sweet spot is making existing Javascript codebases more manageable. It can also be fine in I/O-heavy scenarios where Javascript's async model allows it to perform well despite not having the raw execution performance of lower-level languages.
- capitol_ 1y ago
  I thought that (for example) deno executed typescript natively?
  - wiseowise 1y ago
    It executes typescript without you compiling it to JavaScript first, it doesn’t make code execution any faster.
IshKebab 1y ago
Depends what you mean by slow. The Typescript code was 3x slower than the Go code, and a 3x overhead is pretty much the best you can do for a dynamically typed language. Languages like Python and Ruby are much much slower than that (CPython is easily 10x slower than V8) and people don't seem to care.
EMM_386 1y ago
At the risk of feeling silly for not knowing this ... why is TypeScript considered a programming language, and how can you make it "faster"? I have used its it came out so I do know what it is, but I have people ask if they should write their new program in TypeScript, thinking this is something they can write it in and then run it. My usage of it is limited to JavaScript, so I see it as adding a static typing layer to JavaScript, so that development is easier and more logical, and this typing information is stripped out when transpiled, resulting in pure JavaScript which is all the browser understands. The industry calls it a programming language, so I do too just because this is not some semantic battle I want to get into. But in my mind it's not. There's probably a word for what it is, I just can't think of it. Type system? And I don't understand a "10x speedup" on TypeScript, because it doesn't execute. I can understand language services for things like VS Code that handle the TypeScript types getting 10x faster, but not TypeScript itself. I assume that is what they are talking about in most cases. But if this logic isn't right, let me know.
- flohofwoe 1y ago
  The "10x speedup" is for the compilation step from TS to JS, eg how much faster the new Typescript compiler is, not the runtime performance of the JS output. Theoretically(!) using TS over JS may indirectly result in slightly better perf though because it nudges you towards not mutating the shape of runtime objects (which may cause the JS engine to re-JIT your code). The extra compilation step might also allow to do some source-level optimizations, like constant folding. But I think TS doesn't do this (other JS minifiers/optimizers do though).

tgma 1y ago

In my experience, Go is one of the best LLM targets due to simplicity of the language (no complex reasoning in the type system or borrow checker), a high quality, unified, and language-integrated dependency ecosystem[1] for which source is available, and vast training data. [1]: Specifically, Go community was trained for the longest time not to make backward-incompatible API updates so that helps quite a bit in consistency of dependencies across time.

weinzierl 1y ago
AFAIK the borrow checker is not strictly needed to compile Rust. I think one of the GCC Rust projects started with only a compiler and deferred adding borrow checking later.
- deleted 1y ago
  [deleted]
- tgma 1y ago
  Not that much different than a type checker in any language (arguably it is the same thing). I have been using various LLMs extensively with Rust. It's not just borrow checker. The dependencies are ever-changing too. Go and Python seem to be the RISC of LLM targets. Comparatively, the most problematic thing about generated Go code is the requirement of using every imported package and declared symbol.
- steveklabnik 1y ago
  The borrow checker does not change behavior, so any correct program will be fine without borrow checking. The job of borrow checking is to reject programs only. mrustc also does not implement a borrow checker.
KRAKRISMOTT 1y ago
Well it certainly makes error handling easy. No need to reason about complex global exception handlers and non-linear control structures. If you see an error, return it as a value and eventually it will bubble up. If err != nil is verbose but it makes LLMs and type checkers happy.

wiseowise 1y ago

A tooling team selects language widely used in tooling circles - wild, shocking.

lelanthran 1y ago

> And a surprising level of speedup. Not surprising at all; I keep pointing out that the language benchmarking game is rarely, if at all, reflective of real-world usage. Any time you point out how slow JS is someone always jumps up with a link to some benchmark showing that it is only 2x slower than Go (or Java, or whatever). The benchmarks game, especially in GC'ed languages, are not at all indicative of real-world usage of the language. Real world usage (i.e. idiomatic usage) of language $FOO is substantially different from the code written for the benchmarks games.

igouy 1y ago
Perhaps "real-world usage" is "… rarely, if at all, reflective of [other] real-world usage …". Perhaps when you write "idiomatic usage" you mean un-optimized.

dgb23 1y ago

It doesn't surprise me at all. Idiomatic Go leans on value types, simple loops and conditionals, gives you just enough tools to avoid unnecessary allocations, doesn't default to passing around pointers for everything, gives you more control over memory layout. JS runtimes have to do a lot of work in order to spit out efficient code. It also requires more specialized knowledge from programmers to write fast JS. I think esbuild and hugo are two programs that showcase this pretty well. Esbuild specifically made a splash in the JS world.

kristianp 1y ago

Here's the FAQs, where they explain the decision to go with Go and not, say, rust. https://github.com/microsoft/typescript-go/discussions/categories/faqs https://github.com/microsoft/typescript-go/discussions/categ... Hejlsberg also says in this video, about 3.3x performance is from going native and the other 2-3x is by using multithreading. https://www.youtube.com/watch?v=pNlq-EVld70&t=51s https://www.youtube.com/watch?v=pNlq-EVld70&t=51s