[eyelidlessness]

This is such a cynical take. The point is to model what types exist at runtime in the type system, so that you can reason about those same runtime types statically. They’re only “fictitious” if they’re defined incorrectly, or if the type system can’t sufficiently express certain of their nuances. The former is usually only the case when developers intentionally work around the safety provided by the type system; the latter is possible, but at this point it’s usually only ever the case for patterns that are hard to reason about regardless of the type system or even the presence of types at all.

[zogrodea]

I find myself inclined to the opinion you're disagreeing with in all honesty.

When defining types in other languages, the task is prescriptive (you specify what fields there are in a type and the runtime accepts this as law), but in Typesxript the task is meant to be descriptive (as you say, one models the types that exist at runtime which is the inverse).

I was excited about Typescript when I learned it, but found myself disillusioned by actual experience when using it (of course others love it and have good reason to). Had defined classes in Typescript so I can have some of my types reflected at runtime.

[quaunaut]

Curious what your issue was with duck-typing. Were you effectively looking to create ADTs that are required to go through a specific step-by-step process, not simply 'look like' the thing that was expected?

If so, you might be interested in [newtype-ts].

[newtype-ts]: https://github.com/gcanti/newtype-ts

[zogrodea]

Thanks for the link. That was exactly my use case and I should remember your helpful suggestion next time I use TS.