37 ms·

A Farewell to FRP

771 points by sharksandwich 10y ago

creshal 10y ago
> 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 10y ago
  I reloaded and it worked.
vvanders 10y ago
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.
krisajenkins 10y ago
This is marvellous. IMO Functional has always been a bigger deal than Reactive. Great to see more of that pursuit of simplicity paying off.
zalmoxes 10y ago
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__ 10y ago
  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 10y ago
    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.
  - skybrian 10y ago
    It is still pre-1.0 and the most recent release changed a lot, so I'd guess there is still opportunity for breakage in the future. But it's hopefully closer now.
- embwbam 10y ago
  Bold move, but a good one, I think. I've been considering starting my students (just friends I mentor) on Elm for a while, but it's only this year I've heard of local companies hiring for Elm here in Salt Lake City.
  - marknadal 10y ago
    I recently moved out to SLC area, shoot me an email aquiva at Google's mail.
- vijayr 10y ago
  What resources are you using to learn Elm?
  - zalmoxes 10y ago
    I used https://pragmaticstudio.com/elm https://pragmaticstudio.com/elm to get me started.
sotojuan 10y ago
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!).
timroy 10y ago
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.
- jiyinyiyong 10y ago
  Might be off topic but I was interested in the "a big atom". Reagent is using a big atom and some small atoms to simulate component state -- which breaks hot code swapping. And I tried a way to abstract out component states into a single atom to fix it by building my own React like library. Now it's "two big atoms" on my side.
  - timroy 10y ago
    Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes. The re-frame readme is epic and worth reading just for its own sake: https://github.com/Day8/re-frame https://github.com/Day8/re-frame Not to get off-topic though! I am used to working with dynamic languages, but I really should work with a typed language. Elm looks like it offers many of the benefits of ClojureScript, but with typing as well. Also, ClojureScript lets you write HTML and CSS in your code, but a quick web search indicates Elm may have gone further with incorporating CSS (?).
    - Skinney 10y ago
      Elm incoperates CSS the same way Clojurescript and React incorporates CSS.
      - timroy 10y ago
mswift42 10y ago
Does Elm have any nice interfaces for common JS frameworks? (like reagent / om in clojurescript, or angular2 for dart / typescript)
- snuxoll 10y ago
  Elm doesn't really "need" interfaces to react/angular/whatever, the Elm Architecture defines a standard way to write a reactive application in pure Elm (in a style similar to react/redux).
  - drdaeman 10y ago
    So Elm is only usable for new projects (or rewrites from scratch) and can't be "tried out" if you have some existing mess of a code and want to replace some especially ugly chunk of it (or write a new feature) - just to see how it goes?
    - zalmoxes 10y ago
      No that's not true. Richard from NRI wrote a great blog post about just "trying out" elm in your React app. http://tech.noredink.com/post/126978281075/walkthrough-introducing-elm-to-a-js-web-app http://tech.noredink.com/post/126978281075/walkthrough-intro...
    - seddona 10y ago
      We use Elm inside Angular in production. On https://circuithub.com/projects/ti/TIDA-00230 https://circuithub.com/projects/ti/TIDA-00230 most of the drawing is Elm.
- skybrian 10y ago
  Ports were the way to do this in Elm. I don't know how it works in the new version.
  - jmite 10y ago
    They do, and have been made much clearer: http://guide.elm-lang.org/interop/javascript.html http://guide.elm-lang.org/interop/javascript.html
Keats 10y ago
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/AmxE3qAmtvE https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...
- dominotw 10y ago
  Yep every 'native' library needed arduous review process via github issues. I waited for over a month for elm overlords to approve my 'native use' library , they simply closed the issue. Dropped elm for react and co. Now I have serverside rendering, code splitting, working debugger ect which was impossible with elm. This was last year though so not sure if it is still the process. YMV.
  - jmite 10y ago
    It has changed, in that the language is moving away from Native code, and instead is trying to provide the web-platform as part of the language/core libs. And for everything else, there's Ports. You can't use them in libraries, but for your own projects they're a much better JS FFI.
    - dominotw 10y ago
      >And for everything else, there's Ports. Ports are extremely tedious to use if you are doing anything even moderately complicated .
- embwbam 10y ago
  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.
TY 10y ago
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.
jtwebman 10y ago
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.
rtpg 10y ago
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...
salimmadjd 10y ago
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.
zachrose 10y ago
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?
- vvanders 10y ago
  First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/ http://guide.elm-lang.org/ > No runtime errors in practice. No null. No undefined is not a function. > Friendly error messages that help you add features more quickly. > Well-architected code that stays well-architected as your app grows. > Automatically enforced semantic versioning for all Elm packages.
  - riffraff 10y ago
    to be fair, all these things do not seem to be dependent on this new Subscriptions thing, as in fact they were there even before. I am sure the new idea is good, but as grandparent said, the examples fail to convey why this is better than what we had before.
    - masklinn 10y ago
      The "new Subscriptions" thing replaces signals, which is not what GP thinks is "what we had before".
- wheatBread 10y ago
  They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what? So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.
  - 10y ago
empath75 10y ago
Is parsing json still an ugly mess? That was what put me off actually using it for anything.
- jmite 10y ago
  Under "other cool stuff" it's mentioned that error reporting when parsing fails is greatly improved. Not sure if that's what you meant.
- ccapndave 10y ago
  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 10y ago
    didn't know about this! thanks!
skybrian 10y ago
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.
zellyn 10y ago
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?
- dreamdu5t 10y ago
  Elm does things the same way. However, PureScript has lenses so the same thing can be done if you're using the equivelant of Elm in purescript, purescript-pux
- masklinn 10y ago
  > 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.
- Scarbutt 10y ago
  As far as I understand Om.next still uses a "giant blob of state" - a global atom. It differs from re-frame/reagent in how you access this state, the global atom.
pklausler 10y ago
Stupid question from an interested outsider: how's a "subscription" different from a good ol' callback?
- wheatBread 10y ago
  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 :)
e0m 10y ago
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 10y ago
  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 10y ago
    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.
    - sotojuan 10y ago
      > 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. This really hasn't been the case for RxJS at all. It's been praised and version 5 is largely a community effort rather than just an MS effort. You got Ben Lesh and Andre Staltz putting in the most work and neither are MS. The only thing from MS people don't seem to give a chance is .NET. Everything recent (VS Code, open sourcing stuff, Chakra engine, etc) has been met positively and not dismissed.
miguelrochefort 10y ago
Congrats, you just invented Reactive Extensions...
wyager 10y ago
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 10y ago
  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 10y ago
    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.
d0m 10y ago
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))
- redka 10y ago
  Since with The Elm Architecture parent always takes care of it's children you can create a "Context" and pass it along.
- ccapndave 10y ago
  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.
junke 10y ago
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 10y ago
  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.
  - tormeh 10y ago
    Check out http://www.ceu-lang.org/ http://www.ceu-lang.org/ Then you can try it yourself.
  - junke 10y ago
    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/).
hbrid 10y ago
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.
gjolund 10y ago
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 10y ago
  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..
ccapndave 10y ago
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 :)
- timroy 10y ago
  "if it compiles, then it just seems to work" Man, now that is tempting. Also, how easy are the ports? In ClojureScript you can use JavaScript pretty directly, but I often got a bit hung up translating the syntax (it's not that hard, it was just me).
  - ccapndave 10y ago
    I've never used ClojureScript so I can't speak for that, but the ports are now a lot easier in 0.17 as an outgoing port is simply a function that you can call, instead of messing about with Signals. Effectively, you send stuff to Javascript by calling the port function with a Javascript compatible value, and then you subscribe to messages on the way back in, which end up triggering a message on the update function of whatever component sent it out in the first place. TL;DR its pretty easy once you've done it a few times
  - Skinney 10y ago
    Ports are essentially event emitters. You can expose them from elm, and in your JS code you attach event handlers to them using .onMessage (I think, been a while). You can post and receive messages from ports (depending on type). Type checking is done at runtime to make sure nothing breaks. Cljs interop is easier (can just call a function directly).
  - mgold 10y ago
wrong_variable 10y ago
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.
avindroth 10y ago
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.
dreamdu5t 10y ago
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 10y ago
  Wow, the buttons demo looks very, very close: http://guide.elm-lang.org/architecture/user_input/buttons.html http://guide.elm-lang.org/architecture/user_input/buttons.ht... 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 10y ago
    Yeah, Pux can do server-side rendering, and PureScript can be used with webpack alongside other JS. PureScript also has a much easier FFI.
stepvhen 10y ago
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 10y ago
  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.
jweir 10y ago
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 10y ago
  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.
daxfohl 10y ago
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 10y ago
  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.
millstone 10y ago
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 10y ago
I wish Elm's blog had an RSS feed.
nilkn 10y ago
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.
- knewter 10y ago
  Then you'll probably be very excited to read about http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Process http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Pro...
  - nilkn 10y ago
    Well, BEAM has supervisors, supervision trees, loads of support for fault tolerance, automatic usage of multiple cores, and it easily scales to multiple nodes as well. Simple actor-based concurrency is possible in many languages. Also, even if Elm were to get all that stuff, it'd still be compiling to JavaScript and aimed at web apps. (Don't get me wrong, I'm super excited to see Elm getting support for message-passing lightweight processes. I love Elm, have used it myself for several projects, and think this looks great for web development. I just want something like Elm, but specifically geared towards large-scale backend services instead of front-end apps.)
    - doppioslash 10y ago
      No actually, if you read the announcement you'll find that Elm is keeping platform specific code in the Platform module, to not be locked into being a Javascript-only language forever. So maybe it would take some time, months, years, but Elm could end up running on the BEAM.
    - kika 10y ago
      Purescript? I moved over to it from Elm, exactly because I needed to share the code between frontend and backend and realized that I can't really use Elm on the backend without much effort and risk. Purescript is closer to Haskell than Elm though and as such less "beginner friendly". Monads, typeclasses all that scary stuff. But somehow I handle it okay.
tunesmith 10y ago
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 10y ago
  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.
knewter 10y ago
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!
Learn2win 10y ago
Are there type classes in Elm?
- doppioslash 10y ago
  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
rdtsc 10y ago
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
kgr 10y ago
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
malandrew 10y ago
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 10y ago
  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.
  - pedalpete 10y ago
    I've been thinking about this myself. I've been looking at doing some typescript stuff as I can share code between back and front-end still (and I'm moving into doing some IoT stuff in JS). I'd consider Elm if I could run it everywhere, but it feels to me like at the moment it is browser focused.
  - Gaelan 10y ago
    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 10y ago
      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
  - pdamoc 10y ago
    There are experiments with using Elm on the server via Node. Since you mentioned NoRedInk, they had a sample project that bundled several available technologies: https://github.com/NoRedInk/take-home https://github.com/NoRedInk/take-home It is worth noting that with the advent of 0.17, Elm on server is getting closer to reality. The issue now is for Evan to properly understand what the best approach is. My hope is that we will end up with something like Servant in Elm. In a lot of things Elm is not aiming at WOM but WOFO. In other words, not for libraries that gets most word of mouth but libraries that get word of f-ing obvious. That requires a more deliberate and slower process but the payout is huge.
charlieflowers 10y ago
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 10y ago
  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 10y ago
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...)
- jmite 10y ago
  It should at least be able to compile with GHC 7.10 now.
- maxthegeek1 10y ago
  You can install elm with npm.
john-kelly 10y ago
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
ryenus 10y ago
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.
iamwil 10y ago
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 10y ago
  > 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.
  - iamwil 10y ago
    Yeah, it's true. Logically, I know it's better to catch it all at compile time. But it just feels things are broken all the time, since I don't get to watch my program run nearly as much as I use to. However, when it runs, it usually does work. I think I'm just not as use to structuring my programs in FP yet.
  - garfieldnate 10y ago
    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 10y ago
      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_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...
acqq 10y ago
For those like me who aren't familiar with Elm: An Introduction to Elm https://www.gitbook.com/book/evancz/an-introduction-to-elm/details https://www.gitbook.com/book/evancz/an-introduction-to-elm/d...

771 points by sharksandwich 10y ago

> 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 10y ago
I reloaded and it worked.

vvanders 10y ago

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.

krisajenkins 10y ago

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

zalmoxes 10y ago

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__ 10y ago
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 10y ago
  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.
- skybrian 10y ago
  It is still pre-1.0 and the most recent release changed a lot, so I'd guess there is still opportunity for breakage in the future. But it's hopefully closer now.
embwbam 10y ago
Bold move, but a good one, I think. I've been considering starting my students (just friends I mentor) on Elm for a while, but it's only this year I've heard of local companies hiring for Elm here in Salt Lake City.
- marknadal 10y ago
  I recently moved out to SLC area, shoot me an email aquiva at Google's mail.
vijayr 10y ago
What resources are you using to learn Elm?
- zalmoxes 10y ago
  I used https://pragmaticstudio.com/elm https://pragmaticstudio.com/elm to get me started.

sotojuan 10y ago

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!).

timroy 10y ago

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.

jiyinyiyong 10y ago
Might be off topic but I was interested in the "a big atom". Reagent is using a big atom and some small atoms to simulate component state -- which breaks hot code swapping. And I tried a way to abstract out component states into a single atom to fix it by building my own React like library. Now it's "two big atoms" on my side.
- timroy 10y ago
  Yeah, after the app grew a bit, I had state scattered here and there. re-frame solves this with a big atom, and avoids expensive rendering every time the big atom updates with subscriptions. Subscriptions hold reactions, which only update if the underlying value changes. The re-frame readme is epic and worth reading just for its own sake: https://github.com/Day8/re-frame https://github.com/Day8/re-frame Not to get off-topic though! I am used to working with dynamic languages, but I really should work with a typed language. Elm looks like it offers many of the benefits of ClojureScript, but with typing as well. Also, ClojureScript lets you write HTML and CSS in your code, but a quick web search indicates Elm may have gone further with incorporating CSS (?).
  - Skinney 10y ago
    Elm incoperates CSS the same way Clojurescript and React incorporates CSS.
    - timroy 10y ago

mswift42 10y ago

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

snuxoll 10y ago
Elm doesn't really "need" interfaces to react/angular/whatever, the Elm Architecture defines a standard way to write a reactive application in pure Elm (in a style similar to react/redux).
- drdaeman 10y ago
  So Elm is only usable for new projects (or rewrites from scratch) and can't be "tried out" if you have some existing mess of a code and want to replace some especially ugly chunk of it (or write a new feature) - just to see how it goes?
  - zalmoxes 10y ago
    No that's not true. Richard from NRI wrote a great blog post about just "trying out" elm in your React app. http://tech.noredink.com/post/126978281075/walkthrough-introducing-elm-to-a-js-web-app http://tech.noredink.com/post/126978281075/walkthrough-intro...
  - seddona 10y ago
    We use Elm inside Angular in production. On https://circuithub.com/projects/ti/TIDA-00230 https://circuithub.com/projects/ti/TIDA-00230 most of the drawing is Elm.
skybrian 10y ago
Ports were the way to do this in Elm. I don't know how it works in the new version.
- jmite 10y ago
  They do, and have been made much clearer: http://guide.elm-lang.org/interop/javascript.html http://guide.elm-lang.org/interop/javascript.html

Keats 10y ago

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/AmxE3qAmtvE https://groups.google.com/forum/#!topic/elm-discuss/AmxE3qAm...

dominotw 10y ago
Yep every 'native' library needed arduous review process via github issues. I waited for over a month for elm overlords to approve my 'native use' library , they simply closed the issue. Dropped elm for react and co. Now I have serverside rendering, code splitting, working debugger ect which was impossible with elm. This was last year though so not sure if it is still the process. YMV.
- jmite 10y ago
  It has changed, in that the language is moving away from Native code, and instead is trying to provide the web-platform as part of the language/core libs. And for everything else, there's Ports. You can't use them in libraries, but for your own projects they're a much better JS FFI.
  - dominotw 10y ago
    >And for everything else, there's Ports. Ports are extremely tedious to use if you are doing anything even moderately complicated .
embwbam 10y ago
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.

TY 10y ago

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.

jtwebman 10y ago

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.

rtpg 10y ago

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...

salimmadjd 10y ago

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.

zachrose 10y ago

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?

vvanders 10y ago
First page of the Elm guide covers it pretty well: http://guide.elm-lang.org/ http://guide.elm-lang.org/ > No runtime errors in practice. No null. No undefined is not a function. > Friendly error messages that help you add features more quickly. > Well-architected code that stays well-architected as your app grows. > Automatically enforced semantic versioning for all Elm packages.
- riffraff 10y ago
  to be fair, all these things do not seem to be dependent on this new Subscriptions thing, as in fact they were there even before. I am sure the new idea is good, but as grandparent said, the examples fail to convey why this is better than what we had before.
  - masklinn 10y ago
    The "new Subscriptions" thing replaces signals, which is not what GP thinks is "what we had before".
wheatBread 10y ago
They key difference is that when you create an event emitter in JS, you now have a resource to manage. Where does that go in your app? In each component? How does the component know how to turn these off if it is no longer in use? In the root? How does the root know who needs what? So basically, the difference is in resource management. The web socket example makes this clearer. You never have to ask "who owns the connection?" to use the connection.
- 10y ago

empath75 10y ago

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

jmite 10y ago
Under "other cool stuff" it's mentioned that error reporting when parsing fails is greatly improved. Not sure if that's what you meant.
ccapndave 10y ago
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 10y ago
  didn't know about this! thanks!

skybrian 10y ago

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.

zellyn 10y ago

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?

dreamdu5t 10y ago
Elm does things the same way. However, PureScript has lenses so the same thing can be done if you're using the equivelant of Elm in purescript, purescript-pux
masklinn 10y ago
> 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.
Scarbutt 10y ago
As far as I understand Om.next still uses a "giant blob of state" - a global atom. It differs from re-frame/reagent in how you access this state, the global atom.

pklausler 10y ago

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

wheatBread 10y ago
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 :)

e0m 10y ago

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 10y ago
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 10y ago
  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.
  - sotojuan 10y ago
    > 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. This really hasn't been the case for RxJS at all. It's been praised and version 5 is largely a community effort rather than just an MS effort. You got Ben Lesh and Andre Staltz putting in the most work and neither are MS. The only thing from MS people don't seem to give a chance is .NET. Everything recent (VS Code, open sourcing stuff, Chakra engine, etc) has been met positively and not dismissed.

miguelrochefort 10y ago

Congrats, you just invented Reactive Extensions...

wyager 10y ago

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 10y ago
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 10y ago
  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.

d0m 10y ago

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))

redka 10y ago
Since with The Elm Architecture parent always takes care of it's children you can create a "Context" and pass it along.
ccapndave 10y ago
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.

junke 10y ago

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 10y ago
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.
- tormeh 10y ago
  Check out http://www.ceu-lang.org/ http://www.ceu-lang.org/ Then you can try it yourself.
- junke 10y ago
  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/).

hbrid 10y ago

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.

gjolund 10y ago

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 10y ago
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..

ccapndave 10y ago

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 :)

timroy 10y ago
"if it compiles, then it just seems to work" Man, now that is tempting. Also, how easy are the ports? In ClojureScript you can use JavaScript pretty directly, but I often got a bit hung up translating the syntax (it's not that hard, it was just me).
- ccapndave 10y ago
  I've never used ClojureScript so I can't speak for that, but the ports are now a lot easier in 0.17 as an outgoing port is simply a function that you can call, instead of messing about with Signals. Effectively, you send stuff to Javascript by calling the port function with a Javascript compatible value, and then you subscribe to messages on the way back in, which end up triggering a message on the update function of whatever component sent it out in the first place. TL;DR its pretty easy once you've done it a few times
- Skinney 10y ago
  Ports are essentially event emitters. You can expose them from elm, and in your JS code you attach event handlers to them using .onMessage (I think, been a while). You can post and receive messages from ports (depending on type). Type checking is done at runtime to make sure nothing breaks. Cljs interop is easier (can just call a function directly).
- mgold 10y ago

wrong_variable 10y ago

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.

avindroth 10y ago

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.

dreamdu5t 10y ago

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 10y ago
Wow, the buttons demo looks very, very close: http://guide.elm-lang.org/architecture/user_input/buttons.html http://guide.elm-lang.org/architecture/user_input/buttons.ht... 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 10y ago
  Yeah, Pux can do server-side rendering, and PureScript can be used with webpack alongside other JS. PureScript also has a much easier FFI.

stepvhen 10y ago

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 10y ago
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.

jweir 10y ago

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 10y ago
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.

daxfohl 10y ago

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 10y ago
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.

millstone 10y ago

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 10y ago

I wish Elm's blog had an RSS feed.

nilkn 10y ago

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.

knewter 10y ago
Then you'll probably be very excited to read about http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Process http://package.elm-lang.org/packages/elm-lang/core/4.0.0/Pro...
- nilkn 10y ago
  Well, BEAM has supervisors, supervision trees, loads of support for fault tolerance, automatic usage of multiple cores, and it easily scales to multiple nodes as well. Simple actor-based concurrency is possible in many languages. Also, even if Elm were to get all that stuff, it'd still be compiling to JavaScript and aimed at web apps. (Don't get me wrong, I'm super excited to see Elm getting support for message-passing lightweight processes. I love Elm, have used it myself for several projects, and think this looks great for web development. I just want something like Elm, but specifically geared towards large-scale backend services instead of front-end apps.)
  - doppioslash 10y ago
    No actually, if you read the announcement you'll find that Elm is keeping platform specific code in the Platform module, to not be locked into being a Javascript-only language forever. So maybe it would take some time, months, years, but Elm could end up running on the BEAM.
  - kika 10y ago
    Purescript? I moved over to it from Elm, exactly because I needed to share the code between frontend and backend and realized that I can't really use Elm on the backend without much effort and risk. Purescript is closer to Haskell than Elm though and as such less "beginner friendly". Monads, typeclasses all that scary stuff. But somehow I handle it okay.

tunesmith 10y ago

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 10y ago
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.

knewter 10y ago

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!

Learn2win 10y ago

Are there type classes in Elm?

doppioslash 10y ago
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

rdtsc 10y ago

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

kgr 10y ago

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

malandrew 10y ago

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 10y ago
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.
- pedalpete 10y ago
  I've been thinking about this myself. I've been looking at doing some typescript stuff as I can share code between back and front-end still (and I'm moving into doing some IoT stuff in JS). I'd consider Elm if I could run it everywhere, but it feels to me like at the moment it is browser focused.
- Gaelan 10y ago
  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 10y ago
    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
- pdamoc 10y ago
  There are experiments with using Elm on the server via Node. Since you mentioned NoRedInk, they had a sample project that bundled several available technologies: https://github.com/NoRedInk/take-home https://github.com/NoRedInk/take-home It is worth noting that with the advent of 0.17, Elm on server is getting closer to reality. The issue now is for Evan to properly understand what the best approach is. My hope is that we will end up with something like Servant in Elm. In a lot of things Elm is not aiming at WOM but WOFO. In other words, not for libraries that gets most word of mouth but libraries that get word of f-ing obvious. That requires a more deliberate and slower process but the payout is huge.

charlieflowers 10y ago

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 10y ago
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 10y ago

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...)

jmite 10y ago
It should at least be able to compile with GHC 7.10 now.
maxthegeek1 10y ago
You can install elm with npm.

john-kelly 10y ago

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

ryenus 10y ago

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.

iamwil 10y ago

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 10y ago
> 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.
- iamwil 10y ago
  Yeah, it's true. Logically, I know it's better to catch it all at compile time. But it just feels things are broken all the time, since I don't get to watch my program run nearly as much as I use to. However, when it runs, it usually does work. I think I'm just not as use to structuring my programs in FP yet.
- garfieldnate 10y ago
  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 10y ago
    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_guide/defer-type-errors.html https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...

acqq 10y ago

For those like me who aren't familiar with Elm: An Introduction to Elm https://www.gitbook.com/book/evancz/an-introduction-to-elm/details https://www.gitbook.com/book/evancz/an-introduction-to-elm/d...