No, it's referring to formal methods. Elm will prevent you from writing a binary search that returns a string, but will happily admit a broken binary search that (say) never terminates, or always returns 0. Formal methods allow you to catch that class of mistakes.
I don't see any case for a functional-programming inspired change now. 30 years ago programmers were enlighten by LISP, 15 years ago I was enlightened by OCaml, and today's generation is enlightened by Haskell, or in your case Elm. What's different now?
If anything I think we're moving in the opposite direction. Development speed is now king, and deployment is easier than it's ever been, which means that bugs are less costly to fix. Bondage-and-discipline type languages that promise fewer bugs for more work are just less relevant.
I've recently tried out Elm [1] and have come away with a similar perspective on functional programming and static typing. The benefits I noticed are:
- Because of the static typing and strict management of data/state, the compiler is very good at telling you where the errors in your code are.
- If the compiler is happy, there are essentially no runtime errors.
- While I didn't write any tests, unit testing seems like it would be trivial because every function is stateless.
- You're forced to write better code. I find that Elm is pleasantly constraining. It's an opinionated language that forces you into certain design patterns, but they always seemed like the design pattern I should be using anyway.
Overall, I haven't been more impressed by a language since I discovered Ruby a decade ago. If you could do backend development in Elm I would probably try using it as my primary language.
1. If anyone else is interested, I went through the Pragmatic Studio Elm course: https://pragmaticstudio.com/courses/elm. I have no affiliation with them, just thought it was a really well done course and would recommend it to others who want to try out Elm.