Let me be honest, but this article is just horrible. The whole article is for the sake of complaining (though I prefer to call this "nitpicking").
> 1. Interfaces with excess properties
... in immediate objects, which will never be reused. This is nothing worse than golang emitting errors on every single unused variable. There are good reasons to behaviours like this, even though not always preferable.
> 2. Classes (nominal typing)
It seems like the author straight rejects the idea of structural typing itself, by calling the concept itself a "quirk". This is rather about preference, not right-and-wrong. If this point is to be true, one should also reject duck typing, many other popular dynamic languages, a large portion of software industry, scientific researches, etc. Good luck with that.
> 3. Discriminated Unions
While I do agree that it's a shortfall of TS type system, the example is simply unrealistic. Using composite values as type discriminator is a bad design. Plus, the compiler is not even allowing anything destructive nor bug-prone.
> 1. Interfaces with excess properties
... in immediate objects, which will never be reused. This is nothing worse than golang emitting errors on every single unused variable. There are good reasons to behaviours like this, even though not always preferable.
> 2. Classes (nominal typing)
It seems like the author straight rejects the idea of structural typing itself, by calling the concept itself a "quirk". This is rather about preference, not right-and-wrong. If this point is to be true, one should also reject duck typing, many other popular dynamic languages, a large portion of software industry, scientific researches, etc. Good luck with that.
> 3. Discriminated Unions
While I do agree that it's a shortfall of TS type system, the example is simply unrealistic. Using composite values as type discriminator is a bad design. Plus, the compiler is not even allowing anything destructive nor bug-prone.