TypeScript is an incredible language in general.

The fact that Functions are Objects that can have properties/methods is supremely undervalued.

Are there other languages that do this so nicely? It's the perfect blend of OO and functional.

Programming is mostly about gradually figuring out the right design I find. JS/TS let's me evolve things naturally without big rewrites.

    function foo() {}
    function bar() {}
    function baz() {}
    const commands = [foo, bar, baz]
    // Run commands
    commands.forEach(x => x())

    foo.help = 'This does something'
    // Describe commands
    commands.forEach(x => console.log(x.help))

    // Add some state via closure.
    const config = {}
    function foo() { config.blah }

    // Add some state using partials.
    function _foo(config) { config.blah }
    const foo = foo.bind(null, config)

This premature naming of things in OO creates so many dramas.

It avoids things like `VideoCompressor#compress()`, `VideoSplitter#split()`. You don't have to think: what state belongs in which class...you just call the function and pass it what it needs.

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.

Very much apropos:

Going between Rust and TS it is painfully obvious how much sth like tagged enums are missing, which can also be seen in this post.

I know of this [1] proposal for ADT enums which looks like it has stalled. Anyone know of other efforts?

[1] https://github.com/Jack-Works/proposal-enum/discussions/19

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!)

It sure is. For anyone looking into Compilers and just starting out, I recommend this book: https://keleshev.com/compiling-to-assembly-from-scratch/

The author uses a TypeScript subset to write a compiler to 32bit ARM assembly and explains that it almost looks like Pseudocode, so it is very accessible. A sentiment I can get behind, despite avoiding it in any case possible.

To OP: You could avoid the visitor by using an IIFE style switch using the run utility fn:

    export const run = <T>(f: () => T): T => f();

    const inferred_type = run(() => {
      switch(blah) {
        ...
      }
    })

As some how is writing a compilter in TS, I agree it's not too bad. I started with Deno like the author but ended up switching to Bun which, despite some rough edges, I'm enjoying more than Deno and it's _very_ quick! (My main niggle with Bun is the test reporting, but it's getting the job done)

For standard parser generator frontend, Ohm-js[1] is quite pleasant. I wouldn't recommend anyone reviews the offical tsc compiler, it's huuuge - instead there's mini-typescript[2] (in particular the centi-typescript branch[3]) which does a nice job illustrating how tsc is working.

[1] https://ohmjs.org/ [2] https://github.com/sandersn/mini-typescript/ [3] https://github.com/sandersn/mini-typescript/tree/centi-types...

Looking forward to GC an DOM access in WASM.

That is surprising, I would've thought that TS would have more overhead because of the interfaces adding extra weight. Makes me wonder what else TS could apply to. Language parsing, maybe?

The result shouldn't be all that surprising considering the TypeScript compiler is written in...TypeScript. So TypeScript as a ML is already battle tested and is in heavy production use every day.

Ive been writing compiler in C# and I dont see anything fancy here except union type

Ive personally decided to avoid visitor pattern bloat and Im waiting for closed enum feature in order to have compile time exhaustive check

I really don't know what the author means by "language-centric" vs "implementation-centric" and "production-ready"...

Can I humbly add "Anders Hejlsberg" to the list of reasons why none of the commenters seem surprised?

Not that surprising: https://news.ycombinator.com/item?id=37039443

Of course, that one has been downvoted to -4 (as of now).

It’s just not the right tool for the job .

every day we stray further from God

I'm sick of seeing overly complicated TypeScript code. Mainly overly complicated types.

As the post nicely demonstrates, TypeScript is definitely not OK for compilers (and not surprising at all!)

It doesn't even have destructuring pattern matching!

At this point, even Java is better [1].

[1] https://github.com/tomprimozic/caya/blob/master/src/caya/Int...

Gut reaction is to use LLVM for everything...

it isn't, i have codebase in golang that is much larger than typescript and it is pleasant to work with lsp and compiles smoothly. With typescript i have to turn off lsp and even after that it takes long time too compile. There is a reason why people are writing typescript compiler in rust.

But to what end? For a compiler, there is no need for all the overhead of npm (usually), ts, tsconfig, package.json bundler and bundler configuration, to get something usable, unless one really wants a JS thing at the end to run in the browser. I imagine even some webassembly tool chains may be shorter.