[belmont_sup]

Responding to your gradual typing anti-pattern bit: Agree that dynamic language behaviors can be extreme but it’s also easy to get into crazy type land. Putting aside a discussion of type systems, teams can always add runtime checks like pydantic to ensure your types match reality.

Sorbet (Ruby typechecker) does this where it introduces a runtime checks on signatures.

Similarly in ts, we have zod.

[MeetingsBrowser]

> teams can always add runtime checks like pydantic to ensure your types match reality.

That's the problem with bugs though, there's always something that could have been done to avoid it =)

Pydantic works great in specific places, like validating user supplied data, but runtime checks as a replacement for static type checkers are not really feasible.

Every caller would need to check that the function is being called correctly (number and position of args, kwarg names, etc) and every callee would need to manually validate that each arg passed matches some expected type.

[eternityforest]

Pydantic also takes CPU time and doesn't do anything till runtime.

Type checking is real time in the IDE and lets you fix stuff before you waste fifteen minutes actually running it.

[belmont_sup]

To be clear, I myself prefer sound type systems.

But the reality is that teams have started with untyped Python, Ruby, and Javascript, have been productive, and now need to gradually add static types to remain productive.

> Every caller would need to check that the function...

The nice part here is where the gradual part comes in. As you are able to type more of your code, you're able to move where you add your runtime validation, and eventually you'll be able to move all validation to the edges of your system.

[Spivak]

pydantic does have @validate_call for this use-case.

[guappa]

Profile it and see how much slower it gets :)