Preventing Type Errors
Last week I’ve been reading the docs of some popular JavaScript frameworks. For some reason I stopped when I read type annotations.
#Diagnosis: type error
The thought, that went through my head was: these type annotations are not enforced by anything. They can change at any time or somebody does not read them and the program crashes.
Then I realised again how Elm has changed my perspective on software.
Preventing type errors in JavaScript is time consuming.
The JS community has a lot of software engineering practices to keep the number of type errors to a minimum. Yet all of them are fundamentally different: they are diagnostic.
#How type errors can be prevented
Elm on the other hand almost completely prevents all type errors with a combination of:
- static types
- immutable values
- boundary checks
- exhaustiveness checking
- Maybe type
TypeScript and flow prevent some type errors by adding static types, but leave out a huge list of possible errors caught by the other mechanisms.
With other words static types alone do not guarantee no type errors. The range of type safety across statically typed languages is big.
Maybe we should call languages that almost completely prevent type errors reliable languages. Elm is definitely one of them.