
A Farewell to FRP - sharksandwich
http://elm-lang.org/blog/farewell-to-frp
======
ccapndave
I moved from React/Redux/Typescript to Elm a few months ago, and I'm now on my
second serious project with it, making mobile application with Cordova. I've
found it an absolute pleasure to use, and I especially like that you can be
pragmatic about it; if there is something that is annoying to do in Elm then
you can simply drop into Javascript/Typescript using ports.

Coming from languages like Actionscript/Javascript/Typescript/PHP I have found
the whole Elm experience quite mindblowing; if it compiles, then it just seems
to work. I hardly ever find myself poring over bits of code trying to debug a
subtle error, and if I do the problem is going to be in the
Javascript/Typescript bit.

Basically, I'm sold :)

~~~
christophilus
>> if it compiles, then it just seems to work

This. I spent the first 14 years of my career in statically typed languages
and only this year began working professionally on a Rails app... I _really_
miss the compiler.

~~~
astrodust
Rust has some really good compile-time checking, it really makes you express
everything in a completely non-ambiguous way.

C++ on the other hand compiles stuff that may or may not work at all, it
doesn't care, which can lead to all sorts of undefined behaviour down the
road.

Compilers are not all created equal.

~~~
SomeCallMeTim
Huh. I find that when my C++ compiles, it almost always works. Correctly.

But I used the language for nearly 20 years, so maybe it's experience and the
patterns I've learned?

Not that Rust or Elm aren't _better_ options; don't know, really. Despite
feeling like I'm an expert in C++, I don't actually _like_ the language much.
I've used Go some, and I like it, but I haven't tried Rust or Elm yet.

~~~
marcosdumay
Well, I find that when my C++ compiles <segmentation fault>

When I first learned Java, still in my undergrad, my first impression (and
nearly everybody's) was that when it compiles it works. It was still more work
than Perl, Lisp, Prolog, and everything, but didn't require the annoying C
debugging cycle.

But, anyway, all that is kids play near Haskell.

~~~
powersurge360
Hello! I don't know if English is your first language or not, but that last
sentence was significantly confusing that I wanted to correct it for you and
others who may read it.

The two idioms are 'child's play' & 'next to'. The words are correct synonyms
but the usage is unusual enough that I read as having a totally different
meaning my first time.

~~~
danek
I was also confused by it. However I read the last sentence as the author
making a meta-point by using purposefully incorrect grammar, a sort of
reversal of the first sentence about c++ code compiling but leading to
segfault--like an artistic statement. If it was an accident, then all the
better!

~~~
marcosdumay
:)

English is not my first language, and it is a rare construct. I thought it was
correct.

Out of curiosity, how should it read?

~~~
Crespyl
I believe the common form is "X is child's play (next to|compared to) Y".

------
junke
I am happy to see Elm evolving and it looks like a good framework, but there
is a tendency in FRP articles to ignore prior work, as acknowledged at the end
of the article:

> Note: Interested readers may find Lucid Synchrone interesting. Unfortunately
> for me, I had no idea my thesis had so much in common with synchronous
> programming languages at the time, but the connections are quite striking. I
> might argue that Elm was never about FRP.

My thesis was related to synchronous programming languages and articles about
FRP tend to have too little to say about them, for my taste. Yes, there is a
word or two in the related work, but also it looks like some wheels are being
reinvented.

The subscriptions model reminds me of Esterel, which is imperative and uses
await/emit pairs. In the domain of GUIs, which is related to Elm, there is
ReactiveML (see "ReactiveML, Ten Years Later"
([https://www.di.ens.fr/~pouzet/bib/ppdp15.pdf)](https://www.di.ens.fr/~pouzet/bib/ppdp15.pdf\))).
Look also at Lustre or Signal, with Signal allowing directives to define
multiple execution units: this is used to generate concurrent programs
exchanging values with message passing.

The domain is different, though. Synchronous languages do not target web
interfaces. They are about embedded systems and as such, they are mostly
static. On the other hand, they are compilable into a simple event loop with
static memory usage and constant execution time. Maybe some of the existing
research could be useful to something like Elm, even if it does not target the
same problems.

~~~
faizshah
I was interested in the synchronous languages but never got around to reading
more in depth about them. Can you recommend a book on the subject?

The two languages I was most interested in were Lustre and Esterel.

~~~
junke
Synchronous Programming of Reactive Systems, Halbwachs

Synchronous Languages for Hardware and Software Reactive Systems, Berry

Designing Embedded Systems with the SIGNAL Programming Language, Gamatié

The Synchronous Languages 12 Years Later ([http://www-
verimag.imag.fr/~halbwach/PS/iee03.pdf](http://www-
verimag.imag.fr/~halbwach/PS/iee03.pdf))

There are some resources at Verimag ([http://www-
verimag.imag.fr/Tempo,32.html?lang=en](http://www-
verimag.imag.fr/Tempo,32.html?lang=en)) and the Esterel website ([https://www-
sop.inria.fr/meije/esterel/esterel-eng.html](https://www-
sop.inria.fr/meije/esterel/esterel-eng.html)). You can search the HAL database
too (hal.inria.fr) and maybe have a look at SCADE ([http://www.esterel-
technologies.com/products/scade-suite/](http://www.esterel-
technologies.com/products/scade-suite/)).

~~~
iheartmemcache
I'm a huge INRIA fan so I decided to play with Esterel a while back. If people
call Haskell an 'academic' language, I have no idea how an average person
would describe Esterel. "Thinking in" Esterel is going to be a huge shift for
the traditionally trained CS guy who's never touched a circuit. Half the
people in our field didn't even go to go to school for CS[1]. Hell, I've got a
decent amount of LabVIEW and Verilog experience, and even I have trouble with
it.

That being said, it's interesting and those resources are definitely going on
the Kindle. Do you have a link to your thesis ? (Judging by your comment
history, it has a high likelihood of being quality).

[1] Not to denigrate those who were less traditionally educated. The brightest
engineer I know is a high-school drop-out. They however were motivated enough
to read Sipser, Gunter, B Peirce, and all the standard texts (again, not as a
requirement to read All The Fancy Books, but just to enrich his own mind for
the sake of knowledge - without that curiosity, one might have a difficult
time being more than a code-monkey (not that there's anything wrong with that,
but I personally have the scratch of "how does this work" that I need to keep
on itching compulsively)).

~~~
junke
> Do you have a link to your thesis?

There is only a French version:

[https://tel.archives-ouvertes.fr/tel-00680308/](https://tel.archives-
ouvertes.fr/tel-00680308/)

The context is about using a constraint programming approach (in Prolog) to
model Lustre/Scade programs and automatically generate traces of input/outputs
that satisfy a given test objective. With the help of my advisers I extended
the GATeL tool to introduce what is known as "clocks" in Lustre and integrate
them with other constraint domains to prune the search space efficiently.

~~~
vanderZwan
I get the impression that synchronous programming is somehow only really known
inside the French PL community, is that correct?

~~~
junke
Synchronous programming is mostly a French thing but as far as I know there is
also Quartz in Germany ([https://es.cs.uni-
kl.de/publications/datarsg/Schn09.pdf](https://es.cs.uni-
kl.de/publications/datarsg/Schn09.pdf)), Ptolemy in Berkeley
([http://ptolemy.eecs.berkeley.edu/publications/papers/01/sr/s...](http://ptolemy.eecs.berkeley.edu/publications/papers/01/sr/sr.pdf))
and some work at Virginia Tech
([https://theses.lib.vt.edu/theses/available/etd-08112011-1613...](https://theses.lib.vt.edu/theses/available/etd-08112011-161349/unrestricted/Jose_BA_D_2011.pdf)).

------
zalmoxes
As someone who is just getting started with frontend development, I decided to
go with Elm instead of learning JS and React. I found the whole experience
very pleasant, even as a beginner.

Not only is the elm code I write reliable, but I've found that adding more
features does not bloat my code. Refactoring a codebase as it grows in elm is
pleasant, and following the Elm Architecture guides me on the correct
structure for the app.

Over the weekend I made a small site to show all Elm conference videos in one
place. If you want to play around with 0.17 this project is just a bit above a
"Hello World" example. Send a PR!
[https://elmvids.groob.io/](https://elmvids.groob.io/)

~~~
k__
Nice to read.

Last time I tried Elm, (1 or 1 1/2 years ago) tutorials and docs were kinda
outdated. Got errors in this REPL thing they got for beginners on the webpage
and nothing from the examples worked :\

~~~
mjs2600
I came back to it recently after a year and a half long break and it has
improved dramatically. It's starting to feel like something I'd be comfortable
using in production.

------
e0m
There's also a lot of similarity with Rx.JS and observable based (aka
"Reactor") patterns:

    
    
        Rx.Observable.fromTime().subscribe(tick)
    
        Rx.Observable.fromSocket(mySocket).subscribe(handleEvent)
    

[https://github.com/Reactive-Extensions/RxJS](https://github.com/Reactive-
Extensions/RxJS)

Regardless of the exact library or pattern, the broader concept of treating
data sources as asynchronous event streams you can subscribe and react to
definitely simplifies data flow and makes systems very robust.

An additional benefit of this pattern is the natural way it makes it easy to
filter, chain, map, etc onto these subscriptions. Once again from the Rx
world, [http://rxmarbles.com/](http://rxmarbles.com/) does a great job
visualizing these patterns.

~~~
WorldMaker
I think that's my biggest question reading the article here: Has Elm been
ignoring the work going on with Rx all this time?

These Elm subscriptions sound like "half" of Rx, and from what I can is still
'missing' thus far some of the "higher order" Observable tools such as filter,
chain, map, throttle, et al.

~~~
iheartmemcache
After reading the article, I went into their IRC chan to post this question
(i.e. are they leveraging all the research from really-smart(TM) PhD's at
Microsoft Research & production testing that Rx has behind it). This guy has a
doctorate, so I'd imagine there was a reason why RxJS wasn't leveraged,
especially since it seems like a natural fit especially with Typed.*. And n
general the Elm/Haskell community is way less fan-boi-trendy-node-js-macbooks-
Rails-flavor-of-the-wheel guys who will nay-nay anything that is Microsoft.

I'd love to make the Elm jump, but it still has the Haskell stigma (not enough
engineers making hiring difficult, too 'academic', etc) where my clients
(enterprise) won't let me dev with it. They do however let F# in some
projects. MS should do what they did for OCaml -> F#, but for Elm ->
something_I_can_say_is_first_party_MS_supported.

~~~
WorldMaker
I feel some of this.

I almost had a Microsoft-first shop let me use Haskell when I pointed out how
many of Haskell's lead developers worked at Microsoft Research UK.

As for the Microsoft "first party" F# equivalent for the web, that would be
Typescript. Typescript's typing isn't yet to the rigor of OCaml, much less
Haskell or Elm, but it's getting better every release.

~~~
weq
I learnt Haskell at uni in 2000. Now im a c# guy mostly unless im in the
broswer. You know u can program in pretty much the same way using C# as u can
haskell? I dont see the attraction of going to F#, but thats because i need to
consider maintaince costs of the code-base as well as them both compiling down
to IL.

Functional langauges are great, dont get me wrong, if i had the choice id
probably give 'elixir' a 'rust' ;) but i make do with my existing c#
knowledge, sprinkle in some Rx, isolate my side-effects in closures when pure
functions cant be had, and im pretty happy with both the look, readability and
maintance burden my code generates. The advantage of C# here over a first
order functional lanuage is my ability to customise the syntax to make things
self-documenting as well.

------
timroy
This looks very cool.

In ClojureScript, we have the re-frame pattern/framework, which is built on
Reagent, which is a ClojureScript wrapper of React.

re-frame is all about subscriptions, using a "big atom" to hold application
state client-side. Seeing Elm implement the same subscription pattern makes it
look pretty tempting.

My understanding is that ClojureScript and Elm have some similarities -
functional, pleasant to work with - with one significant difference being that
Elm is typed.

~~~
hkjgkjy
Elm is typed, Clojurescript is homoiconic. 2 great features.

Wondering if you could make a lisp where `lambda` or `fn` required type
annotations, such as

    
    
        (defn add 
          [int -> int -> int] ;; type annotation
          [x y] ;; arguments list
          (+ x y))
    

Then it would be homoiconic - something that has saved me hundreds of lines of
code (and the less code, the less bugs as a rule of thumb).

Then every function down to the very basic lisp functions would have types.
Dunno how doable this is - but it doesnt matter. Someone implemented it in
Common Lisp in the 80s I'm sure.

~~~
hencq
There's Typed Racket [1] and for Clojure there's core.typed [2]which do pretty
much that. For Clojure there's also Schema [3], which is a bit lighter weight
(it's not a full type system), but still gets you some of the benefits like
validation and documentation.

[1] [https://docs.racket-lang.org/ts-guide/](https://docs.racket-lang.org/ts-
guide/) [2]
[https://github.com/clojure/core.typed](https://github.com/clojure/core.typed)
[3] [https://github.com/plumatic/schema](https://github.com/plumatic/schema)

~~~
hkjgkjy
Neither fit the bill though - because not every function ever written in the
language is annotated. To be nice to use, it should be an all-or-nothing
affair.

I say this as a huge clojure fan - my clojure programs with dynamic types work
great. I rely on predicates (functions ending in -?) in I/O, otherwise I'm
sure things work.

~~~
sgrove
Why is annotation important? I agree it needs to be possible, but ultimately I
want to push the majority off into inference, and only explicitly annotate
when necessary or formalizing interfaces OCaml-style.

Though I sure do wish I could have lisp (or clojure, specifically) syntax in
OCaml-land.

------
salimmadjd
Congrats to Evan. I'm still learning Elm and it has been such a pleasure. It's
so much clearer to understand the code and go back to it later. I spoke with
Evan at length at one of the regular Elm "hackathons" in SF and was so
impressed how he thinks about long-term vision of Elm and prefers to take his
time to ensure he gets it right to make Elm be around for a long while. Which
is the reason I'm investing time into Elm. If you're in SF Bay area. Tomorrow
(Wed) is the next Hack night a great place to talk to Evan and the small
community around it.

------
Keats
I like Elm but its development really seems to rely on a single person. I saw
this post on elm-discuss which is a pretty good summary of my thoughts
[https://groups.google.com/forum/#!topic/elm-
discuss/AmxE3qAm...](https://groups.google.com/forum/#!topic/elm-
discuss/AmxE3qAmtvE)

~~~
embwbam
Evan wants to design Elm as thoughtfully as he can, and has been deliberately
resisting community evolution. Eventually it will get too big and too useful,
and he'll lose the ability to make big breaking changes easily. So he's tried
to maintain control of the direction of the language and community during
these early years while he figures it out. He's trying to reduce the feedback
loop and come up with the best possible base before it starts to scale.

It feels like it's stabilizing. I expect that over the next year or so this
will change dramatically and it will become much more community driven.

~~~
dominotw
' during these early years' should feature prominently in their docs/website
if that is case.

If you go to [http://elm-lang.org/](http://elm-lang.org/) they make it looks
like its production ready. No mention of breaking changes/beta ect. You have
to choose one or the other .

~~~
GavinMcG
The version number starting with a zero really ought to denote that,
notwithstanding the JS crowd's seemingly fast and loose approach.

------
malandrew
Since people in this thread are likely to be elm enthusiasts and know what's
going on in the ecosystem, what is the largest high quality elm app you know
about and what is the largest high quality elm app that is open-source that
you know about?

I've been doing backend work for a while and I'd like to see what is possible
these days with elm.

~~~
notduncansmith
I think NoRedInk, who employs Evan (author of Elm); they also host Elm meetups
in SF and are a really friendly bunch.

On an unrelated note, I haven't found much prior work here but I think Elm on
the backend (via Node.js) could be fantastic.

~~~
Gaelan
There's always Haskell. :)

On a slightly more serious note, I wonder if Haskell and Elm are similar
enough that model-style code could be written in a shared subset and run on
both sides.

~~~
pdamoc
They are close enough that people have produced tools like elm-servant that
generates Elm code from Servant code.

[https://github.com/mattjbray/servant-
elm](https://github.com/mattjbray/servant-elm)

------
knewter
I'm super excited for this change. I've been watching and waiting for a few
weeks. It's a big ordeal for me personally, because I've got 10 weeks of daily
elm tutorial content I've written so far at
[http://dailydrip.com/topics/elm](http://dailydrip.com/topics/elm) that I'm
now re-writing, but the changes are all for the better and the language
adoption is bound to go up over time.

If you haven't yet tried Elm, give it a shot. A co-worker (hi Heath!) showed
it to me 4(?) years before I got interested in it, and I brushed it off as a
toy because I was against Functional Programming at the time for terrible
reasons. It's actually one of the 'this feels like the future' technologies
that's re-shaping how I think about programming these days. Huge kudos for the
release!

------
zachrose
I haven't dabbled in Elm much, but subscriptions look a lot like ordinary JS
event handlers:

    
    
        Time.every second Tick
    

vs.

    
    
        Time.on('everySecond', tick)
    

Beyond baking an event emitter into the Time module and having a nice looking
API, is there something I'm missing?

~~~
jlongster
I don't know anything about Elm subscriptions yet. But there is a lot more to
this stuff then just event emitters.

Things like:

* When an event/action/etc comes through, does it always call listeners synchronously? Can you change that and schedule events manually?

* How do you compose subscriptions/event handlers? This is usually the hardest part, and where simple event emitters really start breaking

* What about the lifecycle of the listener? What happens when it subscribes or unsubscribes? More importantly, what happens when the source that it subscribed to "shuts down"?

All of these things get pretty complicated and is the reason why various
fields like FRP exist. Simple event emitters work immediately, yes, but they
are a pretty terrible abstraction to build an app on.

~~~
smrtinsert
Yeah the same questions popped up in my head. The natural end point to me
looks more like Rx. Lifecycle and especially composition seem like big missing
pieces.

------
nilkn
What I really want is a language with Elm's type system, simplicity, and
syntax, but aimed for backend software instead of HTML apps and with strong
support for an Erlang-style actor model of multicore, distributed concurrency.
Basically something like Elixir, but with Elm's syntax and type safety. In the
meantime Elixir will do for me, but I'd really like more type safety without
going full Haskell.

~~~
bmichel
Did you try dialyzer for Erlang[1] or Elixir[2]?

[1]:
[http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html](http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html)
[2]: [http://elixir-lang.org/docs/stable/elixir/typespecs.html](http://elixir-
lang.org/docs/stable/elixir/typespecs.html)

Not sure it helps, it's on my todo list.

~~~
bjz_
Despite some niceties like union types, Dialyzer is pretty limited. For
example, here is example of something I would expect to be able to express in
a modern type system but is not possible with Dialyzer (as far as I know):

    
    
        @spec foo[a: SomeProtocol & SomeBehaviour](a, a) :: a
    

I've also noticed that it lets through stuff that I would expect to fail to
compile, so it's hard to trust as I would a type system like Elm's, Haskell's
or Rust's. The Elixir devs have done a great job with the language, and it's
great to see the resurgence of interest in BEAM as a result, but I still
really wish they had taken the opportunity to build in a decent type system...

------
krisajenkins
This is marvellous. IMO Functional has always been a bigger deal than
Reactive. Great to see more of that pursuit of simplicity paying off.

------
rdtsc
There is a nice talk from Erlang Factory 2016 called

"Making the Web Functional with Phoenix and Elm"

[https://www.youtube.com/watch?v=XJ9ckqCMiKk](https://www.youtube.com/watch?v=XJ9ckqCMiKk)

------
pklausler
Stupid question from an interested outsider: how's a "subscription" different
from a good ol' callback?

~~~
wheatBread
I think it is worthwhile stopping by the Elm slack channel to ask this. You
have framed the question in a weird way. The answer is kind of "these things
are not really related in any direct way" but I feel like you are asking a
different question. Point is, ask on the slack channel and folks will help
clarify :)

------
zellyn
Just out of curiosity. I'm trying to decide which client-side
framework/language to dive into, and it seems that many people consider Om
Next a really nice step forward, away from "giant blob of state". My
(uninformed) observation is that Elm does things the way Om (previous) did it:
is that correct? Is Elm aiming to incorporate Om Next's advantages?

~~~
masklinn
> My (uninformed) observation is that Elm does things the way Om (previous)
> did it: is that correct?

It's not, Elm doesn't use cursors and transactional mutations, I'd say the Elm
architecture is closer to a pure single-store Redux: user actions are
dispatched as Sub Action which are run through an update reducer (Action ->
Model -> Model), which is then run through the view (Model -> Html) resulting
in the new UI state.

------
TY
Say what you will about languages that compile to JS, but Elm code looks so
_elegant_ that I just want to use it for aesthetics alone. Major kudos to Evan
for such a wonderful and powerful creation.

------
skybrian
From the Lucid Synchrone paper referenced in the article:

"Synchronous languages are based on the synchronous hypothesis. This
hypothesis comes from the idea of separating the functional description of a
system from the constraints of the architecture on which it will be executed.
The functionality of the system can be described by making an hypothesis of
instantaneous computations and communications, as long as it can be verified
afterward that the hardware is fast enough for the constraints imposed by the
environment."

That sounds a lot like how functional programming works in a browser. If you
assume function calls take zero time (or can be optimized so they're fast
enough) then you end up with event handling and asynchronous I/O. Preemptive
multitasking becomes a non-issue. But long-running computations (where you
actually want to keep some CPUs busy for a while) need to be handled outside
the system.

------
stepvhen
I got into studying FRP around 3 years ago for my senior project. Aside from a
decent, clear explanation, there were hardly any actual implementations of
this allegedly good paradigm (something Evan covered in his thesis, and the
basis for Elm). It seemed like a paradigm that was full of promise and
potential but failed to deliver in any worthwhile way.

(Such was the case for my senior project, studying the viability of Arrowized
FRP in Elm. In short, I concluded that it was nothing but hell and nobody
should bother.)

I am happy to seem Elm drop FRP, even if I wished it could be the savior of
the method. At this point I think it's a troubled concept and should be
limited to old theses.

~~~
Apanatshka
I'm similarly ambivalent. Though Elm and it's flavour of FRP were more of a
hobby (I never turned into an academically valuable thing :) ), I was still
very interested in the roots of the system and how to use and improve it. I
know the change was happening already, that signals were not used much in the
Elm Architecture; I also understand and applaud the simplification. But I'm
still a little sad to see FRP go, it's an interesting idea and does have
potential IMHO.

------
vvanders
Woah, still reading but seems like a big change considering FRP was somewhat
fundamental to Elm.

[edit] Looks like a solid change driving Elm towards easier usage, Signals and
Mailboxes were definitely something that took a while to wrangle correctly.

------
wyager
Elm is very cool and pleasant to use compared to JavaScript, but I have some
reservations. The limited typeclass system (for numbers and such) seems...
questionable. The interaction of what looks like pure declarative syntax and
what is actually impure imperative semantics is confusing to me. I understand
that the author wants to avoid monads and other perhaps somewhat confusing
staples of functional IO, but I'm not sure the cost/benefit of doing it this
way works out.

I will say that Elm is the best JavaScript-targeting platform I have tried! I
have hopes for GHCJS, but it's not near Elm's level of readiness yet.

~~~
jmite
I don't think the semantics are any more imperative than IO in Haskell, it's
just that there's a different abstraction used for dealing with it.

Moreover, Tasks are absolutely monadic, with `andThen` being the bind
operator. Elm just chooses to focus on the individual use-case, as opposed to
focusing on the broader abstraction.

~~~
wyager
What does that mean? I'm not sure how you could get more imperative than IO in
Haskell; that's literally how the language deals with effectful imperative
sequencing.

Which abstraction does elm use? As far as I can see, there is no abstraction.
This is the problem. Effectful code in elm looks syntactically just like pure
code.

------
iamwil
I found that while things worked once it compiled, I spend most of my time
staring at compilation errors, especially as I refactored. So I'm mostly
trading time spend debugging subtle state errors with fixing compile type
errors. It _feels_ not as productive, since I'm usually looking at errors.

Also, I'm still new to FP, so if you go outside of the Elm architecture,
you're going to run into problems, which you're use to solving with specific
tools, but they won't be available. So you'll have to spend time learning how
to compose things in a new way.

~~~
naasking
> So I'm mostly trading time spend debugging subtle state errors with fixing
> compile type errors. It feels not as productive, since I'm usually looking
> at errors.

Strange, because debugging subtle state errors seems far more time consuming
to me than fixing compile-time errors. You have to launch debugging sessions
or insert logging commands and step through reams of code, where compile-time
errors tell you exactly where the problems are.

~~~
garfieldnate
I had trouble because the compiler errors were very hard to understand. If
your code compiles then yeah, you can step through it. If your code does not
compile and you don't understand what the problem is, then you're stuck. This
makes me think it would be interesting to have a step-through compiler. I
don't know if that even makes sense, but it sounds helpful.

~~~
naasking
Haskell has the option to run your code without type checking [1], so this
isn't an inherent limitation to type checking.

[1]
[https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/defer-
type-errors.html)

------
sotojuan
Elm has always been "that language I dabble in every now and then but never
have time for"... good to see it's evolving. Evan and Richard (creator and
main evangelist, respectively) are a great team and I hope them the best (and
I hope I get more time to mess around with Elm!).

------
daxfohl
Wow, this is a surprise. Kind of like a Haskell headline "A Farewell to
Immutability". But sounds like the pros and cons have been well thought out
for the intended use case.

~~~
gohrt
Not quite that extreme. FRP has always been a very awkward way to express
things, even within the functional/immutable world. FRP had already had it's
(small) boom-bust before Elm came on the scene to give it a small revival.

This is a very good change for Elm.

------
d0m
One thing I'm wondering with elm is how does it deal with state across
different components? I.e. where would you put the settings of the current
user and how would you access that within one component? (By component I mean
the (init,update,view,subscription))

~~~
ccapndave
Another approach is to use extensible records, which give you structural
typing similarly to Typescript. This means that you can pass the exact same
state record/object around to different components, but a particular component
might only specify that the state needs to have a `user` property, whereas
another might only specify that the state needs to have a `friends` property.

------
mswift42
Does Elm have any nice interfaces for common JS frameworks? (like reagent / om
in clojurescript, or angular2 for dart / typescript)

~~~
callahad
In general, you're unlikely to need them.

Instead of cobbling together disparate libraries for a virtual dom (React),
state (Redux), immutability (Immutable.js), and types (Flow / TypeScript), the
entire language and its core libraries are developed as a holistic (but still
modular) unit. In this way, Elm is the BSD to JavaScript's GNU/Linux.

Strong typing and immutability are baked directly into the core language, elm-
lang/html includes an efficient Virtual DOM, and Redux-style action / reducer
cycles tend to naturally arise from "The Elm Architecture," and don't need
significant support beyond what's already in the core language.

If you've bought into the React/Redux paradigm, it's worth giving Elm a shot:
the entire language and core libraries are intentionally designed to more
cleanly, reliably, and maintainably implement the same structure.

~~~
bakul
"In this way, Elm is the BSD to JavaScript's GNU/Linux."

Is there X such that X is the Plan9 to Elm's BSD?

~~~
Crespyl
Perhaps Urbit could fit that description?

------
john-kelly
Hey! CodeHS is working on an Elm Course. The vision of the course is to make a
more approachable version of SICP.

The course is still in development, but let us know if you're interested!

[https://codehs.com/info/curriculum/elm](https://codehs.com/info/curriculum/elm)

------
jweir
Has anyone upgraded a non-trivial app from 0.16 to 0.17? Is it pretty simple
to rewrite moving from Signals to Subscriptions? Any advice?

~~~
ccapndave
It took me about a day and half to upgrade a good sized project, and most of
that time was spent sorting out native code. If you don't use native code and
are using StartApp then its a fairly trivial/methodical upgrade process.

------
jtwebman
I love Elm before but now it is even better! I'll make the switch even though
I was almost done with my first app with it.

------
empath75
Is parsing json still an ugly mess? That was what put me off actually using it
for anything.

~~~
ccapndave
Its a little wordy, but now that I'm used to it, it takes no time to write
decoders/encoders. There is also a tool to automatically generate them from
JSON input at [http://noredink.github.io/json-to-
elm/](http://noredink.github.io/json-to-elm/)

~~~
aarpmcgee
didn't know about this! thanks!

------
creshal
> A web handler threw an exception. Details:

> gen/pages/blog/farewell-to-frp.html: getFileStatus: does not exist (No such
> file or directory)

Some caching problem, it seems?

~~~
mjs2600
I reloaded and it worked.

------
charlieflowers
So, is it still true to say, "You wish you could express your business logic
with pure functions. But often you can't because the lack of immutability
hurts performance in various ways. But ELM creates a 'sandbox' in which you
_can_ do so, by letting you write functions which work over time varying
streams instead of stateful callbacks."

If not, which parts changed / how would you revise it?

~~~
jmite
I wouldn't say that it's about performance for Elm. Its virtual-dom has been
shown to be wickedly fast with pure code.

It's more that real programs need real effects: you need to send HTTP
requests, read from user input, etc. Elm gives you a managed way to deal with
those effects, while keeping the program declarative, and making as much of
the logic side-effect free as is possible.

------
mhd
Has the elm installation on Linux improved in recent months? Last time I tried
my system's GHC was too new to install it from source and the node
installation went kablooey in weird parts(too recent ncurses, the automatic
"reactor" browser repl not finding the Html package etc...)

~~~
maxthegeek1
You can install elm with npm.

------
acqq
For those like me who aren't familiar with Elm:

An Introduction to Elm

[https://www.gitbook.com/book/evancz/an-introduction-to-
elm/d...](https://www.gitbook.com/book/evancz/an-introduction-to-elm/details)

------
rtpg
The chat client thing is pretty interesting, but there's this little bit:

> Use the browser API — To get started you just create a new web socket! Well,
> then you need to open the connection. But do not forget to add an onerror
> listener to detect when the connection goes down and try to reconnect with
> an exponential backoff strategy. And ......

How does handling errors happen I wonder. If you take FB messenger for
example, you would queue up a message but if the sending failed you would get
an opportunity to retry/not send it at all.

I suppose in FB's case you could write your own subscription provider...

------
tunesmith
Say a magazine company wants to regularly send issues to a customer, and the
customer signs up. Who has the subscription, the customer, or the magazine
company? Which one subscribes?

According to Rx, it's the magazine company. Which one subscribes? The magazine
company subscribes. It took me a while to realize this when trying to learn Rx
concepts, which made it really confusing, since I've always seen the customer
as being the subscriber, subscribing and owning the subscription.

It looks like Elm is the other way around compared to Rx, I think.

~~~
ccapndave
I suppose if anything it is the customer subscribes. But actually, in
practice, it doesn't really feel quite like this because in FP you just have a
bunch of functions and there isn't the concept of things 'owning' other things
like you have in more OO based language. What actually happens is that you add
a (sort of) listener to the subscription that fires a message in a particular
update function, which manipulates some part of the model.

------
ryenus
FRP = Functional Reactive Programming

> When I started working on my thesis in 2011, I stumbled upon this academic
> subfield called Functional Reactive Programming (FRP). By stripping that
> approach down to its simplest form, I ended up with something way easier to
> learn than similar functional languages. Signals meant piles of difficult
> concepts just were not necessary in Elm.

------
avindroth
I have been learning some haskell, maybe I will dabble in elm. Watched a talk
by Evan and was blown away by time-based sophistication.

------
kgr
FOAM is also subscription based, but then builds FRP on top of it:
[https://www.youtube.com/watch?v=-fbq-
_H6Lf4](https://www.youtube.com/watch?v=-fbq-_H6Lf4)

------
millstone
Can someone explain how the subscription API differs from signals, addresses,
and ports? I'm not familiar with the "old" Elm so I can't judge what the
change is like.

------
leejoramo
I wish Elm's blog had an RSS feed.

------
Learn2win
Are there type classes in Elm?

~~~
doppioslash
No, and they're not planned either. There has been much discussion about them
in the years: [https://github.com/elm-lang/elm-
compiler/issues/1039](https://github.com/elm-lang/elm-compiler/issues/1039)

------
dreamdu5t
Looks like Elm moved closer to Pux's API by dropping the signals for `Html
action`. Check out Pux if you're interested in the same architecture but for
PureScript.

[https://github.com/alexmingoia/purescript-
pux](https://github.com/alexmingoia/purescript-pux)

~~~
masklinn
Wow, the buttons demo looks very, very close: [http://guide.elm-
lang.org/architecture/user_input/buttons.ht...](http://guide.elm-
lang.org/architecture/user_input/buttons.html)

The biggest difference is that the Elm version of "start a simple application"
encapsulates more boilerplate, but I guess pux can do server-side rendering?

~~~
dreamdu5t
Yeah, Pux can do server-side rendering, and PureScript can be used with
webpack alongside other JS. PureScript also has a much easier FFI.

------
wrong_variable
subscriptions are great for handling black hole callbacks - callbacks that you
cannot return back control to the callie.

Examples of this would be web-socket , http-requests , etc.

however elm and cycle.js try to shoe-horn this idea everywhere - which I think
is not needed.

Not every event needs to be subscribed to - it pollutes your global stream.
Use global stream only when you need to deal with things that move out the
execution context of your program.

------
gjolund
Doing away with signals is a great move, everything else about the elm
architecture felt so intuitive.

I'm excited to give elm another shot, and I yearn for the future he describes
where web assembly makes elm a viable js replacement.

~~~
jventura
When I did the tutorials some weeks ago, I also had difficulty understanding
Signals. In the time, it made more sense to me if it was called "Streams"
instead, as I'm used to the concept of signals and slots from Qt, where a
signal is an event that your widgets dispatch and slots are the functions that
react to signals.

These subscriptions from Elm kind-of remind me the signals and slots mechanism
of Qt..

------
hbrid
Looks very good. I got stuck learning elm at about the point I wanted to
integrate a call to a javascript function. Can't for the life of me remember
if that involved signals or not. Will definitely try the tutorial(s) again
when I get some more time because I really was enjoying everything else about
the language and developing in it.

------
miguelrochefort
Congrats, you just invented Reactive Extensions...

