Elm's claim-to-fame type inference is pretty wonderful
No Runtime Exceptions
Elm uses type inference to detect corner cases and give friendly hints. For example, what if someone provides invalid inputs? NoRedInk switched to Elm about two years ago, and 250k+ lines later, they still have not had to scramble to fix a confusing runtime exception in production.
-- TYPE MISMATCH ---------------------------- Main.elmThe1stargumentto`drop`isnotwhatIexpect:8|List.drop(String.toIntuserInput)[1,2,3,4,5,6]^^^^^^^^^^^^^^^^^^^^^^This`toInt`callproduces:MaybeIntBut`drop`needsthe1stargumenttobe:IntHint:UseMaybe.withDefaulttohandlepossibleerrors.
The thing not mentioned that is really the key to this equation is that end-user Elm code cannot perform side effects. So all the code you write in Elm is purely calculation. Combined with the ML-family type system, you almost have to do it on purpose to crash Elm. I've found a case or two that will unexpectedly crash it (e.g. using a HTML attribute with a blank name and value), but caught it right away in dev.
I only mention it because the same type inference is available in other languages (Reason, F#, OCaml). But these languages cannot make the same guarantee since side effects are permitted. This is a pragmatic choice for them, because they are general purpose languages. It is an outstanding wish of mine to be able to mark specific code in F# as side-effect-free and have the compiler enforce that, in case my own discipline slips.
It seems more limiting than it is in practice. But I can imagine Ports (the JS interop) being a pain if you need to integrate a lot of existing JS libraries. They closed the more direct escape hatch (aka native, kernel) in 0.19. And yeah, I have the sentiment that things are a bit too rigidly prescriptive in Elm-land. But it taught me a lot -- especially the depth of what you can do with just calculation. It's hard to go back to anything else after that, because pure calculations are so refactorable and testable. We are trialing Fable-Elmish, which is basically Elm with opt-in side effects. It is written in F#, which is syntactically close to Elm. I even have a strategy for isolating side effects to be able to keep the rest of the code pure.
If that's the case, I would suggest looking into PureScript. I dabbled in Elm a while ago and I really liked it, but I felt that the language had way too many opinions built into it, because it's actually a language and a framework.
PureScript is very similar to Elm, it's also heavily inspired by Haskell, has type inference, and compiles down to Javascript. However, it doesn't have a strict architecture built in and the interoperability with Javascript is a bit more straightforward.
I've been toying with PureScript for a couple of weeks now and, honestly, I'm not sure I'll ever go back to Elm. Plus, you can use PureScript for backend code too.
Elm's claim-to-fame type inference is pretty wonderful
elm-lang.org/blog/compilers-as-ass...
The thing not mentioned that is really the key to this equation is that end-user Elm code cannot perform side effects. So all the code you write in Elm is purely calculation. Combined with the ML-family type system, you almost have to do it on purpose to crash Elm. I've found a case or two that will unexpectedly crash it (e.g. using a HTML attribute with a blank name and value), but caught it right away in dev.
I only mention it because the same type inference is available in other languages (Reason, F#, OCaml). But these languages cannot make the same guarantee since side effects are permitted. This is a pragmatic choice for them, because they are general purpose languages. It is an outstanding wish of mine to be able to mark specific code in F# as side-effect-free and have the compiler enforce that, in case my own discipline slips.
Yes. If anything this has kept me from adopting Elm for real even though I'm fairly enamored by it.
I've always sort of relied on the escape hatch you don't get it Elm. I'm much more used to programming in the chaos of Ruby. 🙃
Some day though. Some day, I'll find the discipline to stick to something like Elm.
It seems more limiting than it is in practice. But I can imagine Ports (the JS interop) being a pain if you need to integrate a lot of existing JS libraries. They closed the more direct escape hatch (aka native, kernel) in 0.19. And yeah, I have the sentiment that things are a bit too rigidly prescriptive in Elm-land. But it taught me a lot -- especially the depth of what you can do with just calculation. It's hard to go back to anything else after that, because pure calculations are so refactorable and testable. We are trialing Fable-Elmish, which is basically Elm with opt-in side effects. It is written in F#, which is syntactically close to Elm. I even have a strategy for isolating side effects to be able to keep the rest of the code pure.
If that's the case, I would suggest looking into PureScript. I dabbled in Elm a while ago and I really liked it, but I felt that the language had way too many opinions built into it, because it's actually a language and a framework.
PureScript is very similar to Elm, it's also heavily inspired by Haskell, has type inference, and compiles down to Javascript. However, it doesn't have a strict architecture built in and the interoperability with Javascript is a bit more straightforward.
I've been toying with PureScript for a couple of weeks now and, honestly, I'm not sure I'll ever go back to Elm. Plus, you can use PureScript for backend code too.
Thanks for the suggestion. I’ve been meaning to try it, but it’s philosophical closeness to Haskell gives me pause.
Oh, hey! I meant to reply to Ben, but apparently we wrote at the same time and you won 😅
Still, if you're familiar with Elm it shouldn't be hard to get the hang of it.