As the ops guy at NRI responsible for Elm, the main source of errors with Elm is actually during builds. From 0.15-0.17, Elm did not correctly handle the caching of artifacts, leading to occasional compile errors that were not reproducable easily. It was simple enough to fix - just wipe the artifacts. But that also slowed the builds down a lot.
I'm also fairly certain I'm the leading expert on runtime exceptions in Elm - it's possible to make them happen, but most of the time you have to really understand Elm to make them happen. Unless you're using Array or Regex, of course. Both of these can lead to runtime exceptions - e.g Regex.regex "[a". However, you'll not likely run into that in production - unless you are taking using input as regex input.. which probably isn't a good idea unless you're escaping things.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
As the ops guy at NRI responsible for Elm, the main source of errors with Elm is actually during builds. From 0.15-0.17, Elm did not correctly handle the caching of artifacts, leading to occasional compile errors that were not reproducable easily. It was simple enough to fix - just wipe the artifacts. But that also slowed the builds down a lot.
I'm also fairly certain I'm the leading expert on runtime exceptions in Elm - it's possible to make them happen, but most of the time you have to really understand Elm to make them happen. Unless you're using Array or Regex, of course. Both of these can lead to runtime exceptions - e.g
Regex.regex "[a". However, you'll not likely run into that in production - unless you are taking using input as regex input.. which probably isn't a good idea unless you're escaping things.