I’m a typing fanatic, so rather predictably I’m going to wade in and an have an opinion.
I think the idea that the value of types comes from catching bug is a misunderstanding of types, or alternatively, is the value of a disappointing and not very useful type system.
I believe that types static analysis is a development tool, and its purpose is to lower the cost of maintenance. If it makes development slower then something has gone wrong, and the tool should be discarded.
I think tests do a better job at catching bugs, but they are not as useful for lowering the cost of editing code.
With sufficiently powerful static analysis it should be relatively easy to step into a large and unfamiliar codebase and start making edits, your editor telling you what you need to do after you’ve told it what kind of change you wish to make.
It’s possible to get a degree of this experience with tests, but they fall down any time you need to make a change to an API or to the behaviour of the program as they verify that the code does what it was intended to do when the tests were written, not what you intend it to do today. Those two things may be different.
Yes, completely!
This is one of the things that for me makes Gleam, Purerl, etc, exciting for the BEAM. We have a wealth of fantastic dynamically typed languages; if we were to have the same quality and robustness for statically types languages we’d have a wider range of programming styles that could draw in even more people to our ecosystem.
I frequently get messages from people saying “I’ve always wanted to try Erlang, but the lack of a static type system meant I didn’t feel it was right for me before”. With Gleam, etc, these people are now trying out the BEAM.
The more BEAMers the better!