>And so has Hejlsberg, apparently, seeing his reasoning for choosing go over C# for tsc

It was more related to the fact that the existing TS code was more easily ported to Go, and also .NET AOT wasn't mature enough at that time. Structural typing has its own problems. I'm personally not a big fan of it.

Might be my own taste, but except a few of the common and easy to understand structural typing code, I find it sometimes actually make things needlessly complex.

I also write lots of Typescript, and the furthest I go is to use 'Omit' and other utility types, but already feel like it's too much.

I've come to really appreciate Typescripts structural typing, because it reduces some of the overhead & prevents the unnecessarily tight coupling that has often annoyed me in other languages.

The overhead argument seems fairly objective to me - clean code with low coupling in C# et al. requires separate definitions of interfaces and implementations, explicit conversion methods between compatible interfaces etc. This adds up over time and makes refactoring pretty annoying.

The tight coupling happens when people don't bother to define interfaces. Suddenly I have to couple class hierarchy to classes from unrelated modules, all so the compiler is happy when I pass structurally equivalent data. To keep my own modules clean I have to add yet more interfaces, conversion methods etc!

It prefer static functions and stuff we can quickly understand, avoiding big objects or a great deal of indirection. Don't tell Uncle Bob!

Of course, you'd still need interfaces for DI, mocking etc, but that's pretty most of my interface usage.

I hope once they introduce unions, they also introduce some sort of error union.