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.
For example, on a web project I had been working on I decided to add the 'search' feature; the very first change[1] actually worked! This is generally not possible with JavaScript.
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.
> I have found the whole Elm experience quite mindblowing; if it compiles, then it just seems to work.
My mindblowing experience was facilitated by referential transparency where I had a page of code that became half a page after extracting some functions and restructuring the code and then have that half page collapse into several lines of boring code because I realized that the functionality can be re-expressed in terms of standard functions.
It is amazing to be able to think about an entire branch of code in isolation and be able to understand it in its entirety.
"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).
Thank you for this endorsement. I am learning Elm, I like it a lot so far, but there are times where I question if this is really all necessary.
So first person experiences like yours help me continue and understand where I can be if I continue on the path I am.
Also, I would like to add that I really liked Signals and felt that they are good abstraction, but looking at Subscriptions and they also on surface level make sense.
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)).
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.
> My thesis was related to synchronous programming languages and articles about FRP tend to have too little to say about them, for my taste.
What would you expect them to say exactly? Synchronous languages are first-order reactive programming, but FRP is about higher-order reactive programming.
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/
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.
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 :\
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/ does a great job visualizing these patterns.
Exactly. Rx was created by MS research for Azure -- mostly to abstract away the threading model in the cloud - why reinvent the wheel when Observable / Rx is built for every platform you use and is fantastic.
When ELM came along with its signals, im like, meh, why not Rx? Im not even going to bother to learn it, your at v0.1 and ur gonna see why u need it soon enough. Subcritiption? Dont reinvent the wheel like Redux? Why not Rx? A few months later, everyone is going "how we we handle async actions properly?" Well thats an Observable my dear friend!
Just like when Flux "came out". They just rebranded Event Sourcing in the client UI.
Im getting pretty fed up with all this mumbo jumbo. I write C# mostly, i like FRP, ES, unidirectional flows. Im going to bring a slim universal c# solution with a typescript/JS bridge to the OSS community. The main philosphy is, one client/server architecture, to build scable responsive apps. With builtin backpressure handling.
If ppl had just embraced Rx like 6years ago when it was first V1'd, imagine how much further along the road we would be now? Like seriously, get over urself OSS fanboys, just cause its MS, doesnt mean its bad.
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.
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.
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.
I personally use ClojureScript with type annotations from Plumatic (former Prismatic) Schema and it works really well. Obviously it's not the same as an actual typed language, but it gives me a good-enough starting point to leverage some typing information and perform some rudimentary (runtime) type checking. I also feel it's really nice as some kind of "inline documentation" to be able to see the type of your parameters (obviously this is a given benefit for statically/explicitly typed languages).
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.
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.
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.
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.
Same here and for that very reason I'll continue playing with Elm (it's fun) but ultimately I'm focusing more on learning Clojurescript as it seems to be the safer "sane" way out of JS/React country, at least for my professional projects.
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.
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 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!
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.
Akka[1] is exactly the library you're looking for. It's available for Scala[2], which lets you use both OOP and FP as needed. (It also runs in Java if you have experience with that.)
For whatever reason the Elixir community doesn't seem to really strongly point people at dialyzer, but what you want is dialyzer, and yes you can use it with Elixir.
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 :)
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?
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.
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.
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.
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.
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.
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.
[+] [-] ccapndave|10 years ago|reply
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 :)
[+] [-] sridca|10 years ago|reply
That's exactly been my experience with Elm.
For example, on a web project I had been working on I decided to add the 'search' feature; the very first change[1] actually worked! This is generally not possible with JavaScript.
[1] https://github.com/srid/chronicle/commit/4a6c18147bf1596b234...
[+] [-] christophilus|10 years ago|reply
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.
[+] [-] pdamoc|10 years ago|reply
My mindblowing experience was facilitated by referential transparency where I had a page of code that became half a page after extracting some functions and restructuring the code and then have that half page collapse into several lines of boring code because I realized that the functionality can be re-expressed in terms of standard functions.
It is amazing to be able to think about an entire branch of code in isolation and be able to understand it in its entirety.
[+] [-] timroy|10 years ago|reply
[+] [-] desireco42|10 years ago|reply
So first person experiences like yours help me continue and understand where I can be if I continue on the path I am.
Also, I would like to add that I really liked Signals and felt that they are good abstraction, but looking at Subscriptions and they also on surface level make sense.
[+] [-] mrcactu5|10 years ago|reply
Perhaps you are using Elm to compile to HTML / CSS / JS which Cordova compiles to native code?
[+] [-] frostymarvelous|10 years ago|reply
My mind was blown but never really got enough time to study it since it was low on my priority list.
I think you just pushed it to #2!
[+] [-] junke|10 years ago|reply
> 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)). 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|10 years ago|reply
The two languages I was most interested in were Lustre and Esterel.
[+] [-] naasking|10 years ago|reply
What would you expect them to say exactly? Synchronous languages are first-order reactive programming, but FRP is about higher-order reactive programming.
[+] [-] zalmoxes|10 years ago|reply
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/
[+] [-] embwbam|10 years ago|reply
[+] [-] k__|10 years ago|reply
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 :\
[+] [-] vijayr|10 years ago|reply
[+] [-] e0m|10 years ago|reply
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/ does a great job visualizing these patterns.
[+] [-] weq|10 years ago|reply
When ELM came along with its signals, im like, meh, why not Rx? Im not even going to bother to learn it, your at v0.1 and ur gonna see why u need it soon enough. Subcritiption? Dont reinvent the wheel like Redux? Why not Rx? A few months later, everyone is going "how we we handle async actions properly?" Well thats an Observable my dear friend!
Just like when Flux "came out". They just rebranded Event Sourcing in the client UI.
Im getting pretty fed up with all this mumbo jumbo. I write C# mostly, i like FRP, ES, unidirectional flows. Im going to bring a slim universal c# solution with a typescript/JS bridge to the OSS community. The main philosphy is, one client/server architecture, to build scable responsive apps. With builtin backpressure handling.
If ppl had just embraced Rx like 6years ago when it was first V1'd, imagine how much further along the road we would be now? Like seriously, get over urself OSS fanboys, just cause its MS, doesnt mean its bad.
[+] [-] WorldMaker|10 years ago|reply
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.
[+] [-] timroy|10 years ago|reply
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|10 years ago|reply
Wondering if you could make a lisp where `lambda` or `fn` required type annotations, such as
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.
[+] [-] Morgawr|10 years ago|reply
[+] [-] jiyinyiyong|10 years ago|reply
[+] [-] salimmadjd|10 years ago|reply
[+] [-] Keats|10 years ago|reply
[+] [-] embwbam|10 years ago|reply
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|10 years ago|reply
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.
[+] [-] musha68k|10 years ago|reply
[+] [-] malandrew|10 years ago|reply
I've been doing backend work for a while and I'd like to see what is possible these days with elm.
[+] [-] notduncansmith|10 years ago|reply
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.
[+] [-] knewter|10 years ago|reply
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|10 years ago|reply
[+] [-] nilkn|10 years ago|reply
[+] [-] bmichel|10 years ago|reply
[1]: http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html [2]: http://elixir-lang.org/docs/stable/elixir/typespecs.html
Not sure it helps, it's on my todo list.
[+] [-] jiaweihli|10 years ago|reply
[1] http://akka.io/ [2] http://www.scala-lang.org/
[+] [-] knewter|10 years ago|reply
[+] [-] zem|10 years ago|reply
[+] [-] el_tone|10 years ago|reply
[+] [-] im_down_w_otp|10 years ago|reply
[+] [-] kreetx|10 years ago|reply
[+] [-] krisajenkins|10 years ago|reply
[+] [-] rdtsc|10 years ago|reply
"Making the Web Functional with Phoenix and Elm"
https://www.youtube.com/watch?v=XJ9ckqCMiKk
[+] [-] pklausler|10 years ago|reply
[+] [-] wheatBread|10 years ago|reply
[+] [-] zellyn|10 years ago|reply
[+] [-] TY|10 years ago|reply
[+] [-] skybrian|10 years ago|reply
"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|10 years ago|reply
(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|10 years ago|reply
[+] [-] vvanders|10 years ago|reply
[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|10 years ago|reply
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.