When I researched elm a few years ago, I pretty much came to the same conclusions that the author came about the hard way. 1. The native / non-native split and

When I researched elm a few years ago, I pretty much came to the same conclusions that the author came about the hard way. 1. The native / non-native split and coming hard deprecation of native, although makes sense from a 'code purity of the ecosystem' perspective, will ultimately be a huge hindrance in practice. 2. Elm specifically puts it's author as the single point of failure, decision making and design, because he wants to make sure the language features are designed right by sacrificing development multithreading. 3. Because of the 2 decisions above, forces elm to effectively be a research / toy language, who's ideas we benefit from the ideas showing up in other languages. Such as elm's error messages probably inspiring rust and swift to improve their error messages. You can't rely on elm as a business. 4. Elm might of been better off not using the browser as it's runtime environment in the end because of the above 3 issues and how bad javascript is and went straight for a flutter or squeak style of implementation setup, which doesn't cause as many 'temptations of native' kinds of issues.