That’s not what I’m saying. I think static typing introduces a certain set of trade offs that some people prefer. You restrict the set of statements that are possible to express to ones that can be checked by the type system, and as a result you get additional compile time guarantees. For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.
you are restricted to a set of statements that can be expressed using a particular type system
What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.
So in such shitty type systems you often have code that’s written for the benefit of the type checker rather than a human reading it. In good type systems any code that’s written for the benefit of the type checker is often an antipattern.
For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.
Rust has HKT support through GATs and typeclass support thru traits. Rust has minimal code you write for the benefit of the type checker.
Typescript technically has HKT support but it’s a coincidence and the Typescript team doesn’t care about it, since the beginning Typescript was made to be Enterprise Javascript by Microsoft. Though systems like fp-ts exist they’re hard to get rolling in enterprise.
Typescript does have problems with code that’s written for the benefit of the type checker rather than a human reading it in a large part due to inefficiencies of the compiler itself. In a small part due to some corner cases that still exist because even though it’s type system while more advanced than others in it’s enterprise grade class, it’s still written in that style for that purpose so the inconsistencies it makes to support the janky workflow (plus some EMCA stuff e.g. Promise is not functionally typeable since the spec breaks set theory for convenience reasons) leads to that problem.
However in Typescript these are avoidable problems and you are able to write code without dealing with the type checker’s bullshit a good amount of the time if you follow the correct patterns – certainly better than any other “enterprise grade” static typing system.
That’s not what I’m saying. I think static typing introduces a certain set of trade offs that some people prefer. You restrict the set of statements that are possible to express to ones that can be checked by the type system, and as a result you get additional compile time guarantees. For example, Lemmy devs prefer this trade off and it has nothing to do with enterprise workflows.
What I’m saying is that most good static typing systems do not practically have such limitations, you’d be very hard pressed to find them and they’d be fairly illogical. Most static typing systems that are used in enterprise do have limitations because they are garbage.
So in such shitty type systems you often have
code that’s written for the benefit of the type checker rather than a human reading it. In good type systems any code that’s written for the benefit of the type checker is often an antipattern.Rust has HKT support through GATs and typeclass support thru traits. Rust has minimal code you write for the benefit of the type checker.
Typescript technically has HKT support but it’s a coincidence and the Typescript team doesn’t care about it, since the beginning Typescript was made to be Enterprise Javascript by Microsoft. Though systems like fp-ts exist they’re hard to get rolling in enterprise.
Typescript does have problems with
code that’s written for the benefit of the type checker rather than a human reading itin a large part due to inefficiencies of the compiler itself. In a small part due to some corner cases that still exist because even though it’s type system while more advanced than others in it’s enterprise grade class, it’s still written in that style for that purpose so the inconsistencies it makes to support the janky workflow (plus some EMCA stuff e.g.Promiseis not functionally typeable since the spec breaks set theory for convenience reasons) leads to that problem.However in Typescript these are avoidable problems and you are able to write code without dealing with the type checker’s bullshit a good amount of the time if you follow the correct patterns – certainly better than any other “enterprise grade” static typing system.