3 ms·
'Of course, they also like to avoid bugs, but for that they use testing.' This is kind of the key bit. To caveat this - I'd like better typing in Erlang, and
by lostcolony 6y ago
'Of course, they also like to avoid bugs, but for that they use testing.'
This is kind of the key bit.
To caveat this - I'd like better typing in Erlang, and when i last used it in production I added type annotations to everything and ran Dialyzer as part of the build. But this is personal preference, and I'm not convinced it was the best use of my time; just the most conservative way to approach things for a system I needed extremely high uptime on.
You have to write tests anyway. Just because a statically typed system compiles doesn't mean your test load is reduced. While it eliminates certain classes of bugs, those same classes mostly get covered just by writing functional tests of sufficient coverage.
Between that, and Erlang's supervision tree (so that if you DO get a type error at runtime, it would be in a path you haven't adequately tested, and so not your expected 'happy path', and as such, can reasonably be restarted), it strikes me as a reasonable position to take.
- loxs 6y agoRegarding dialyzer: Yes, it's sane to use it although it's a massive PITA, especially when you have to collaborate with people who do not write type annotations or use such libraries. Regarding testing - I think it depends on the type of application you are writing. If you need 99.99% uptime, probably you have to have almost full test coverage. But for the kind of software that I write (at least lately), I rely on "let's make illegal states unrepresentable" to a large degree, then write a small number of regression tests (or fix the types) when we find bugs... This has proven (at least to me) to be good enough, especially compared to my clients' previous experience, which is usually very poor: extremely buggy software in a dynamic language with almost no tests and docs. Perfect quality is usually not needed or at least not worth the price.