"Before this release, my primary priority was: prove that FRP is viable and good. If FRP is not the right way, it does not matter how good or bad the type check

"Before this release, my primary priority was: prove that FRP is viable and good. If FRP is not the right way, it does not matter how good or bad the type checker is." This is a lousy justification. If the intent was to prove that FRP was viable and good, why not do it in a dynamic type system? Implementing an extended Hindley Milner inference algorithm can be subtle, so why bother? I can manage a slow type checker, because "eh it's not 1.0", but an unsound type system, no. I've tried Elm because I really wanted to program functionally a small webapp, but the type checker had so many holes in it that I had to translate the algorithms in Haskell, type them and fix them there before porting them back. I'm now really reluctant to try any new version of Elm.