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.
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.
Of course they do, it’s silly to claim otherwise. Some type systems are certainly more flexible than others, but each one necessarily restricts how you can express yourself. Not to mention the fact that advanced type systems introduce mental overhead of their own. The more flexible the type system is the more complex it is as a result. There was even famously a debugger for Scala type system illustrating just how absurd things can get. I’ve used plenty of typed languages including Haskell, so I understand perfectly well how modern static typing works.
Meanwhile, I’d argue that Typescript provides incredibly weak guarantees in practice, and the impact of transpiling on the workflow is not insignificant.
My experience is that immutability plays a far bigger role than static typing in practice. The best pattern for ensuring correctness and maintainability is to break things up into small components that can be reasoned about independently. Any large project can be broken up into smaller parts, and that’s by far the best approach towards ensuring correctness that I’ve seen.
Again, that’s my experience working with many different languages for over two decades now. I’m not suggesting other people can’t have their own preferences.
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.
Of course they do, it’s silly to claim otherwise. Some type systems are certainly more flexible than others, but each one necessarily restricts how you can express yourself. Not to mention the fact that advanced type systems introduce mental overhead of their own. The more flexible the type system is the more complex it is as a result. There was even famously a debugger for Scala type system illustrating just how absurd things can get. I’ve used plenty of typed languages including Haskell, so I understand perfectly well how modern static typing works.
Meanwhile, I’d argue that Typescript provides incredibly weak guarantees in practice, and the impact of transpiling on the workflow is not insignificant.
My experience is that immutability plays a far bigger role than static typing in practice. The best pattern for ensuring correctness and maintainability is to break things up into small components that can be reasoned about independently. Any large project can be broken up into smaller parts, and that’s by far the best approach towards ensuring correctness that I’ve seen.
Again, that’s my experience working with many different languages for over two decades now. I’m not suggesting other people can’t have their own preferences.
deleted by creator