
Faithful Elm and the Amazing Router - amitaibu
http://www.gizra.com/content/faithful-elm-amazing-router/
======
not-much-io
I've gotten into elm recently coming from Clojurescript and reagent (re-frame
to be exact).

I didn't think I needed types, until I tried Elm, now I am seriously having an
identity crisis..

All my backend Python code is also riddled with type hints to help out with
the cognitive load.

Elm - Simple, friendly, helpful

Just wish Elm was more mature, but loving it anyway!

~~~
supster
It would be really cool to have an Elm type language on the backend. Elm feels
like a lighter, friendlier version of Haskell.

~~~
jarcane
Whereas after spending even a day with it I found myself wanting to run
screaming back to Haskell.

No typeclasses, no monads, more primitive pattern matching, no guards, use of
massive nested elseif considered idiomatic ...

Simple tasks wind up feeling tedious because so many of the standard tools and
patterns of any other ML language are simple missing completely. The result
feels like trying to work with one of those random toy Lisps people make in a
weekend and throw up on Github.

It frustrates me, because in theory I do like the concept of the Elm
architecture, I love ML-style type systems, and I work with reactive
programming every day in ClojureScript. But the language it's attached to is
so incomplete that it quickly just becomes a pain.

~~~
noelwelsh
That's exactly the dividing line I see in those who love Elm and those who
don't. People coming from Ruby / JS backgrounds appreciate a modern type
system and it isn't so different from languages they are used to that it is
hard to get going. People already used to modern functional programming miss
the abstractions they are used to that Elm doesn't provide. I find this really
interesting. As a community we don't give enough attention to the sociological
aspects of programming. You can see similar things in the adoption of
languages like Go and Elixir.

~~~
lolive
(Sorry for my poor english but i need some clarification) Do you put Go,
Elixir and Elm is the same bag, i.e langages a step further JS in term of
abstraction, i.e langages easy to understand when you come from plain JS? And
then, you put Purescript and Haskell in another bag, i.e langages with
advanced abstractions absent from "casual" langages, i.e langages requiring a
lot of effort to learn? Did I summarize your idea correctly?

~~~
a-saleh
I think understood the Elm/Haskell/Purescript, i.e:

Javascript dev sees Elm and might think "Wow,a type-system and it is awesome,
didn't expect that"

Haskell dev sees Elm and might think "I am missing so many features with these
types" and consider something else, probably pure-script, that has similar
toolbelt.

Not sure about the rest though.

------
dzdt
For anyone confused like I was, the "Elm" here is a newish in-browser
functional language [1], not an old and venerable unix email client [2].

[1] [http://elm-lang.org](http://elm-lang.org)

[2]
[https://en.m.wikipedia.org/wiki/Elm_(email_client)](https://en.m.wikipedia.org/wiki/Elm_\(email_client\))

~~~
dice
With the addition of "amazing router" in the title I was expecting some modern
iteration of the 500 mile email [1] story.

[1]
[http://www.ibiblio.org/harris/500milemail.html](http://www.ibiblio.org/harris/500milemail.html)

------
deathtrader666
So now I think I should be swapping out Ember for Elm from my PEEP stack
(PostgreSQL + Elm + Elixir + Phoenix).

------
agrafix
Elm's pretty okay, but beware that every update currently has broken all code
written for an older compiler version...

~~~
piotrkubisa
That's true, but after coming from Laravel / PHP stack I don't take it as huge
disadvantage as it was in Laravel. First, because each new breaking feature
comes with a dozen of articles covering changes and how-to. Secondly, I am
person who likes discovering, learning, playing with all these new features, I
don't complain to learn something new. And last argument is that each new
version comes is way more developer-friendly than previous release.

------
lolive
I wonder about the ecosystem of any advanced language running on a JS engine.

Basically, two things may happen in the future:

\- all the libs existing in JS are recoded by dedicated fanatics in the
advanced language. Then you have a versatile all-purpose development ecosystem
with this language.

or

\- you rely upon the existing JS ecosystem and libs, and eventually spend your
time struggling with the impedance mismatch between JS and your advanced
langage.

Did you feel something like that with Purescript, Elm, etc?

~~~
mbrock
I haven't used Elm, but generally I think it shouldn't be that scary to use an
"advanced language" if it has an even remotely decent FFI.

It might seem like horror to have to interface to external dependencies, but
if the libraries you want to access aren't extremely complex then interfacing
with them probably isn't going to be such a huge problem.

In some cases you might want to use the advanced language for some things but
keep the outer layer of the app in JavaScript. At a previous workplace we had
a particularly tricky parsing module written in Fay (Haskell subset compiling
to JS).

~~~
bbaumgar
The latter case has worked out great for us at helme.io. Our computational
forecast library is written in Clojurescipt, while the rest of the application
is in JS + Angular.

A word of warning: with Clojurescript, at least, there is a big cost to
converting between JS and CLJS types. This has been a big painpoint as our
need for frequent calculations increases. Still, we wouldn't have it any other
way.

