Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TypeScript is surprisingly ok for compilers

matklad.github.io

Post reply on HN
Print view View original

31–40 of 245 posts

Re: TypeScript is surprisingly ok for compilers

#31

Post by nikanj »

foldr wrote: post #21
rtpg wrote: post #4

TS's type system is fun but a part of me always wonders how much faster TS's compiler would be if it was written in a compiled language (assuming "good implementation", which is a big assumption!)

Probably not that much faster. V8 is very good at optimizing JS code. Typescript is slow mostly because of the complexity of its type system (which is required to make it backward compatible with existing JS code).

Probably quite a bit faster if you do not have to instantiate a new V8 for every single file, considering how many files your average npm project has. I'm not certain if any contemporary build systems reuse the compiler process for multiple files

Re: TypeScript is surprisingly ok for compilers

#32

Post by xscott »

baq wrote: post #17
lmm wrote: post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

What does a try expression like this do? Returns null/undefined on a throw?

I suspect you could do something like:

    const c = attempt(() => ... );
where attempt invokes the lambda, catches any exceptions, and does what you want

Re: TypeScript is surprisingly ok for compilers

#33

Post by zkldi »

thdespou wrote: post #27
baq wrote: post #17

Earlier quoted context omitted.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

Zig can though: const std = @import("std"); pub fn main() !void { const stdout = std.io.getStdOut().writer(); try stdout.print("Hello, {s}!\n", .{"world"}); }

that's not using `try` as an expression. can you do `let foo = try (plus some handling for diverging in the other case?)`

Re: TypeScript is surprisingly ok for compilers

#34

Post by foldr »

nikanj wrote: post #31
foldr wrote: post #21

Earlier quoted context omitted.

Probably not that much faster. V8 is very good at optimizing JS code. Typescript is slow mostly because of the complexity of its type system (which is required to make it backward compatible with existing JS code).

Probably quite a bit faster if you do not have to instantiate a new V8 for every single file, considering how many files your average npm project has. I'm not certain if any contemporary build systems reuse the compiler process for multiple files

Why would it have to instantiate a new V8 for every file? You can just run 'tsc' in your project dir to compile all Typescript files.

Re: TypeScript is surprisingly ok for compilers

#35

Post by harrygeez »

rtpg wrote: post #4

TS's type system is fun but a part of me always wonders how much faster TS's compiler would be if it was written in a compiled language (assuming "good implementation", which is a big assumption!)

There's an answer from TypeScript team for your question :) https://twitter.com/drosenwasser/status/1260723846534979584

Basically,

> Let's say TypeScript takes over 20 seconds to type-check a medium-sized program. That's not usually because it's JS, it's often because of types that cause a combinatorial explosion.

Also

> A different runtime can afford a lot (it sounds like parallelism and start-up time in this case) but I haven't seen a CPU-bound benchmark that supports the idea of a 20x all-up speed-up.

Re: TypeScript is surprisingly ok for compilers

#36

Post by not_alexb »

baq wrote: post #17
lmm wrote: post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

The biggest expressivity pain point in practice for me is try/catch not being an expression, so I can’t do const c = try { … }

I use iife for stuff like this.

const c = (

    ()=> {
        try: {...}
    }
)()

Re: TypeScript is surprisingly ok for compilers

#37

Post by harrygeez »

foldr wrote: post #34
nikanj wrote: post #31

Earlier quoted context omitted.

Probably quite a bit faster if you do not have to instantiate a new V8 for every single file, considering how many files your average npm project has. I'm not certain if any contemporary build systems reuse the compiler process for multiple files

Why would it have to instantiate a new V8 for every file? You can just run 'tsc' in your project dir to compile all Typescript files.

I think people often underestimate how much the TypeScript team does to make TypeScript fast and efficient. They have some of the best people in the field working on the type checker

Re: TypeScript is surprisingly ok for compilers

#38

Post by zkldi »

paddim8 wrote: post #6
lmm wrote: post #2

Is that really suprising? Typescript is yet another language that has, kicking and screaming, picked up most of the ML featureset. I'd expect it to be, well, fine; the lack of real pattern matching is a pain, so it's going to be inferior to OCaml, but fine, no different from using C# or Swift or Dart or Kotlin or something of that ilk.

I would think C# is easier for this due to having proper (and very convenient) pattern matching.

C# doesn't have anything resembling proper pattern matching. C#s pattern matching is akin to a marginally improved switch or if/else-if chain. C#s pattern matches aren't exhaustive, and the compiler doesn't properly check them at all.[0]

There are no proper sum types in C#, so 80% of the point isn't even there.

    enum Season
        {
        Spring,
        Summer,
        Autumn,
        Winter
    }
...

    int PatternMatch(Season season) =>
    season switch {
        Season.Spring => 1,
        Season.Summer => 2,
        Season.Autumn => 3,
        Season.Winter => 4,
        // compiler can't prove the above code is exhaustive because no proper sum types
        // compiler needs nonsensical branch here that diverges
        _ => throw new ArgumentException("Invalid enum value for command", nameof(command)),
    };

Re: TypeScript is surprisingly ok for compilers

#40

Post by hardware2win »

zkldi wrote: post #38
paddim8 wrote: post #6

Earlier quoted context omitted.

I would think C# is easier for this due to having proper (and very convenient) pattern matching.

C# doesn't have anything resembling proper pattern matching. C#s pattern matching is akin to a marginally improved switch or if/else-if chain. C#s pattern matches aren't exhaustive, and the compiler doesn't properly check them at all.[0] There are no proper sum types in C#, so 80% of the point isn't even there. enum Season { Spring, Summer, Autumn, Winter } ... int PatternMatch(Season season) => season switch { Seaso…

>compiler can't prove the above code is exhaustive because no proper sum types

Thats because c#s enum is not "closed"

https://github.com/dotnet/csharplang/issues/3179

Post reply on HN