I worry that the type system may:
- result in idioms that actually harm code evolution (catch alls/pokemons exhastiveness checks will hide future issues)
- destroy “coding the happy path” and “let it crash” semantics because the type system creates a tension that promotes the use of nanny coding standards / catchalls which may be well intentioned but ultimately harmful.
- not deliver much value vs the significant effort typing “types” to “keep the compiler happy”
- reduce productivity in the wrong place vs testing
- reduce readability, although I think “doctypes” would be a nice way to document possible function return values.
- be at a layer too high. If it’s not in the core of the beam then we lose the potential for exploiting it for optimisation and also may have an impedance mismatch “all bets are off” when using Erlang libraries that don’t use the type system.
- distract the community for a very long time.
- end up with multiple rail gauges in libraries, and it is likely to be polarising to the point some will embrace it and some will despise it.
- lead to similar outcomes like the early days of C programming before function prototypes, and we would need to declare the function twice, one in K&R style and another using the hipster ANSI C style with prototypes which meant using macros to harmonise the code so it could still compile with non ANSI C compilers.
- create a false sense of security. Testing is good, value matching and let it crash is excellent. This already provides more value further than types.
