11 ms·

I've gotten into elm recently coming from Clojurescript and reagent (re-frame to be exact). I didn't think I needed types, until I tried Elm, now I am seriousl

I've gotten into elm recently coming from Clojurescript and reagent (re-frame to be exact). I didn't think I needed types, until I tried Elm, now I am seriously having an identity crisis.. All my backend Python code is also riddled with type hints to help out with the cognitive load. Elm - Simple, friendly, helpful Just wish Elm was more mature, but loving it anyway!

supster 10y ago
It would be really cool to have an Elm type language on the backend. Elm feels like a lighter, friendlier version of Haskell.
- clarus 10y ago
  You can get a "kind of Elm" experience on the backend with Flow and JavaScript / NodeJs. The type system of Flow is not as strict as Elm, but you have the main parts (including disjoint unions) and can use existing JavaScript code. With React and Redux you also get a similar framework for the frontend.
- kawera 10y ago
  Elixir seems a good candidate.
  - nilkn 10y ago
    I'm not sure. I do think Elixir is a great language given its goals, but it's very dynamic, whereas Elm is strongly statically typed.
    - kawera 10y ago
      You are right about the type system but still, Elixir is a lighter, friendlier functional programming language compared to haskel or erlang. Not having previous FP experience, I'm having a good time learning Elixir + Elm.
    - rdtsc 10y ago
      Elixir and Erlang have a type checker as well. Not Hindley–Milner but one called "success typing" and is checked by a tool called Dialyzer. It is rather good actually: http://learnyousomeerlang.com/dialyzer http://learnyousomeerlang.com/dialyzer But is still optional to compile. The more precise and better the type annotations, the more helpful it is. If it can deduce that some inconsistency or type error occurring it will let user know. If it is not sure, it won't say anything. Another point is because of isolated process heaps and extra fault tolerance, it is possible to get a high degree of assurance from a system built in Erlang or Elixir even with dynamic typing. And there are certainly many examples of that.
      - nilkn 10y ago
        Dialyzer is indeed nice, but as you say, it's completely optional, it's not Hindley-Milner, and it relies entirely on thorough, correct type annotations from the developer. Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. So I stand by my point that Elixir is a very different language in practice from Elm.
        rdtsc 10y ago
        I use Erlang and I like it a bit more than Elixir in general exactly because it is more explicit. It involves slightly more syntax but there is less hidden magic stuff happening behind the scene.
        The_suffocated 10y ago
        > Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. This is not true. While Elixir may not make things as explicit as Elm (I don't know Elm well enough to assert or refute such a statement), the author of Elixir has stated in various occasions that Elixir prefers explicit to implicit. For instance, in Elixir, unless one explicitly defines a String.Chars protocol for a data structure, string interpolation of that data structure will not compile. In contrast, pretty much everything can be implicitly interpolated in Ruby. Another example is function calls. In Elixir, if f is not a named function but a variable bound to an anonymous function, you cannot call it by writing something like f(x). Instead, you must put a dot after f and write f.(x) to state clearly that you are calling an anonymous function.
    - dllthomas 10y ago
      Compilation targets for typed languages are very frequently untyped (think ASM, for the most canonical example) - it is neither weird nor difficult.
      - nilkn 10y ago
        Could you clarify? I don't immediately see the relevance of this. Why does it matter if the compilation target is or is not also strongly typed, and how does that imply anything about the experience of using a high-level dynamically typed language vs. a high-level statically typed language?
        dllthomas 10y ago
        I understood the (some number of grands-)parent comment to be saying "Elixir seems a good candidate [for a compilation target]." If that was not your interpretation, then it is certainly non-sequiter. Re-reading, I think I misread something in a surrounding comment, though I'm not sure what.
        kawera 10y ago
        I said "Elixir seems a good candidate" for backend development, not as a compilation target. The OP asked for suggestions regarding light, friendly FP languages for backend dev.
        dllthomas 10y ago
        Yeah - like I said, I think I misread something up-thread, so I had the wrong context in mind.
- masklinn 10y ago
  MLs are fairly close I would think, Elm is syntactically very similar to Haskell but semantically it feels closer to SML or OCaml (without the O part)
  - weavie 10y ago
    Yes. SML really deserves a lot more love.
  - vog 10y ago
    That was my first thought, too: Elm is quite similar to OCaml, so why not using OCaml in the backend? With all that server-side stuff around MirageOS, you can not only build a server app, but a full server VM within OCaml. On the other hand, OCaml also targets JavaScript coding in the browser, via js_of_ocaml or the newer bucklescript. I would be very interested in a comparison of client-side development with OCaml+js_of_ocaml (or OCaml+bucklescript) versus Elm.
- not-much-io 10y ago
  From what I understand Elm is planned to target Node eventually. However the language is pretty young right now and the main work is going into making client side Elm the best it can be. The language author doesn't want to branch out too far.
  - hibikir 10y ago
    Not quite: It's planned to target Beam, Erlang's VM. It's an easy fit for Elm. Still, not going to get done any time soon.
    - twoquestions 10y ago
      Do you have a source for this? I'd be interested in their reasoning. You'd think Beam would be a very different compile target than JS, and it seems weird to make such a huge change without very good reason.
      - pmarreck 10y ago
        I think "massive concurrency" and "bulletproof uptimes" are pretty good reasons. Plus that would then allow Elm on both client and server. The Elm folks have been fairly buddy-buddy with the Elixir/Phoenix folks, so this doesn't surprise me
        twoquestions 10y ago
        That sounds amazing. It makes my heart sing that a different VM than JVM or .Net is gaining more traction, and as a static types fan it makes me happy that a statically typed language may be getting on Beam.
      - knewter 10y ago
        I think the compile target is basically not a big problem, and there's been explicit work to make the Browser just one Platform. Also, see the `Process` module in the core docs for a hint of the future, regardless of where it lands (this would also work well for WebWorkers etc, and is handled right now by a naive scheduler). Concern over the compile target should be super low - if you've built a language of sorts, you should have a feel for how it's not that big of a deal to tweak the target.
- jjnoakes 10y ago
  I'm toying around with PureScript on node. It's not too bad.
- jarcane 10y ago
  Whereas after spending even a day with it I found myself wanting to run screaming back to Haskell. No typeclasses, no monads, more primitive pattern matching, no guards, use of massive nested elseif considered idiomatic ... Simple tasks wind up feeling tedious because so many of the standard tools and patterns of any other ML language are simple missing completely. The result feels like trying to work with one of those random toy Lisps people make in a weekend and throw up on Github. It frustrates me, because in theory I do like the concept of the Elm architecture, I love ML-style type systems, and I work with reactive programming every day in ClojureScript. But the language it's attached to is so incomplete that it quickly just becomes a pain.
  - noelwelsh 10y ago
    That's exactly the dividing line I see in those who love Elm and those who don't. People coming from Ruby / JS backgrounds appreciate a modern type system and it isn't so different from languages they are used to that it is hard to get going. People already used to modern functional programming miss the abstractions they are used to that Elm doesn't provide. I find this really interesting. As a community we don't give enough attention to the sociological aspects of programming. You can see similar things in the adoption of languages like Go and Elixir.
    - deleted 10y ago
      [deleted]
    - lolive 10y ago
      (Sorry for my poor english but i need some clarification) Do you put Go, Elixir and Elm is the same bag, i.e langages a step further JS in term of abstraction, i.e langages easy to understand when you come from plain JS? And then, you put Purescript and Haskell in another bag, i.e langages with advanced abstractions absent from "casual" langages, i.e langages requiring a lot of effort to learn? Did I summarize your idea correctly?
      - a-saleh 10y ago
        I think understood the Elm/Haskell/Purescript, i.e: Javascript dev sees Elm and might think "Wow,a type-system and it is awesome, didn't expect that" Haskell dev sees Elm and might think "I am missing so many features with these types" and consider something else, probably pure-script, that has similar toolbelt. Not sure about the rest though.
- jweir 10y ago
  Have you looked at Reason from Facebook? It is a syntax for OCAML that is a bit simpler - https://facebook.github.io/reason/ https://facebook.github.io/reason/
- TheWiseOne 10y ago
  F# might be worth considering. You can also target JS by using a compiler like Fable (http://fsprojects.github.io/Fable/ http://fsprojects.github.io/Fable/) or FunScript (http://funscript.info/ http://funscript.info/).
- dreamdu5t 10y ago
  There is one: PureScript. You can build node apps with it and use it with webpack. There's even an Elm-like UI library https://github.com/alexmingoia/purescript-pux https://github.com/alexmingoia/purescript-pux
- wyager 10y ago
  Elm is essentially just Haskell with weaker type classes. If you can use Elm, I can't imagine why you'd have trouble using Haskell.
- BenoitP 10y ago
  I have been thinking about toying with JVM's Graal compiler (JIT and customizeable deopts for the price of an interpreter). But with a language that has few corner cases. I was thinking maybe regexes, or brainfuck, or QBasic. I'd just looove to try and put Elm on the JVM, but I just can't at the moment.
shados 10y ago
having types vs having good types is two totally different world. Elm's type system is really awesome. Interaction of simplicity and power. I kind of like to think of it as the Java to late 90s' C++, where "less is more" made it popular.
shrugger 10y ago
Scala.js is a lot of fun, have you considered using it? It's quite further along than Elm at this point.
- not-much-io 10y ago
  The reason I personally haven't looked at Scala (or Scala.js) is the OOP + FP approach. <personal understanding> Scala seems to want to please everyone, having all the tools at hand - Immutable and Mutable collections, Objects and enforced Pure Functions etc. That to me seems like a call for trouble in the community, a split between approaches to problem solving at a fundamental level. </personal understanding> And well one of the things that I love about Elm is the lack of needing to make too many choices because the language doesn't have too many complicated features and prioritises "One good lib over 5 decent libs" (though at this young stage what other option does it have). Clojurescript, Javascript and I'm betting Scala.js offer a lot of solutions to the same problem and/or have fancy language features that I am looking for an escape from. Just personally want to try going back to "less is more", to see what it is like. :)
  - shrugger 10y ago
    Well, Scala was originally designed to complement a platform that encourages mutable data structures. When Scala was first getting started, Java didn't have anonymous functions yet, and it was a different time. Currently, Scala-Native is working on off-JVM Scala, Scala.js is already plenty capable of compiling to efficient JS, and when wasm lands, it'll probably manage that rather easily. Elm is a neat language, but I think it sort of presents too wide a divide. I have the same problem with Elm as I do with Typescript, Dart, and all of the other languages that recognize JS is a shit language, but just compile to it anyways. Scala is a VERY well-designed language, and FP/OOP isn't nearly as polarizing as it might seem. I'd recommend LearnXinY Scala, read a little bit and you might see how natural it actually is (excluding the obnoxious syntax for certain things) But yeah, JS has always been the crucial problem that needs to be solved. *.js is never going to solve it.
    - pmarreck 10y ago
agentgt 10y ago
For me it boils down to variant types (also known as Algebraic Data Types but I prefer the ML nomenclature) and the corresponding pattern matching that comes with it. This is IMO the major feature that makes FP languages so damn safe. Everyone talks about higher order functions and generic types but lots of languages have that.... the really good ones have ADTs. Oh what I would give to have ADTs in Java. I would stop using Exceptions for errors (not all exceptions are bad just most of them). I would stop using the annoying visitor pattern... That reminds me that I need to rexamine Derive4J
- sanderjd 10y ago
  I had a similar epiphany when I started using Rust. I hadn't really understood the power of ADTs, having only come across them in Haskell, until I saw them in an otherwise more familiar language, and it totally changed the way I think about things.
- drudru11 10y ago
  Have you looked at the Yeti language for the jvm?
zem 10y ago
you should enjoy this blog post on thomas leonard's experience porting 0install from python to ocaml: http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain...

supster 10y ago

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

clarus 10y ago
You can get a "kind of Elm" experience on the backend with Flow and JavaScript / NodeJs. The type system of Flow is not as strict as Elm, but you have the main parts (including disjoint unions) and can use existing JavaScript code. With React and Redux you also get a similar framework for the frontend.
kawera 10y ago
Elixir seems a good candidate.
- nilkn 10y ago
  I'm not sure. I do think Elixir is a great language given its goals, but it's very dynamic, whereas Elm is strongly statically typed.
  - kawera 10y ago
    You are right about the type system but still, Elixir is a lighter, friendlier functional programming language compared to haskel or erlang. Not having previous FP experience, I'm having a good time learning Elixir + Elm.
  - rdtsc 10y ago
    Elixir and Erlang have a type checker as well. Not Hindley–Milner but one called "success typing" and is checked by a tool called Dialyzer. It is rather good actually: http://learnyousomeerlang.com/dialyzer http://learnyousomeerlang.com/dialyzer But is still optional to compile. The more precise and better the type annotations, the more helpful it is. If it can deduce that some inconsistency or type error occurring it will let user know. If it is not sure, it won't say anything. Another point is because of isolated process heaps and extra fault tolerance, it is possible to get a high degree of assurance from a system built in Erlang or Elixir even with dynamic typing. And there are certainly many examples of that.
    - nilkn 10y ago
      Dialyzer is indeed nice, but as you say, it's completely optional, it's not Hindley-Milner, and it relies entirely on thorough, correct type annotations from the developer. Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. So I stand by my point that Elixir is a very different language in practice from Elm.
      - rdtsc 10y ago
        I use Erlang and I like it a bit more than Elixir in general exactly because it is more explicit. It involves slightly more syntax but there is less hidden magic stuff happening behind the scene.
      - The_suffocated 10y ago
        > Elixir also follows the Ruby philosophy of hiding as much behind the syntax as possible, whereas Elm tends to be very explicit. This is not true. While Elixir may not make things as explicit as Elm (I don't know Elm well enough to assert or refute such a statement), the author of Elixir has stated in various occasions that Elixir prefers explicit to implicit. For instance, in Elixir, unless one explicitly defines a String.Chars protocol for a data structure, string interpolation of that data structure will not compile. In contrast, pretty much everything can be implicitly interpolated in Ruby. Another example is function calls. In Elixir, if f is not a named function but a variable bound to an anonymous function, you cannot call it by writing something like f(x). Instead, you must put a dot after f and write f.(x) to state clearly that you are calling an anonymous function.
  - dllthomas 10y ago
    Compilation targets for typed languages are very frequently untyped (think ASM, for the most canonical example) - it is neither weird nor difficult.
    - nilkn 10y ago
      Could you clarify? I don't immediately see the relevance of this. Why does it matter if the compilation target is or is not also strongly typed, and how does that imply anything about the experience of using a high-level dynamically typed language vs. a high-level statically typed language?
      - dllthomas 10y ago
        I understood the (some number of grands-)parent comment to be saying "Elixir seems a good candidate [for a compilation target]." If that was not your interpretation, then it is certainly non-sequiter. Re-reading, I think I misread something in a surrounding comment, though I'm not sure what.
        kawera 10y ago
        I said "Elixir seems a good candidate" for backend development, not as a compilation target. The OP asked for suggestions regarding light, friendly FP languages for backend dev.
        dllthomas 10y ago
        Yeah - like I said, I think I misread something up-thread, so I had the wrong context in mind.
masklinn 10y ago
MLs are fairly close I would think, Elm is syntactically very similar to Haskell but semantically it feels closer to SML or OCaml (without the O part)
- weavie 10y ago
  Yes. SML really deserves a lot more love.
- vog 10y ago
  That was my first thought, too: Elm is quite similar to OCaml, so why not using OCaml in the backend? With all that server-side stuff around MirageOS, you can not only build a server app, but a full server VM within OCaml. On the other hand, OCaml also targets JavaScript coding in the browser, via js_of_ocaml or the newer bucklescript. I would be very interested in a comparison of client-side development with OCaml+js_of_ocaml (or OCaml+bucklescript) versus Elm.
not-much-io 10y ago
From what I understand Elm is planned to target Node eventually. However the language is pretty young right now and the main work is going into making client side Elm the best it can be. The language author doesn't want to branch out too far.
- hibikir 10y ago
  Not quite: It's planned to target Beam, Erlang's VM. It's an easy fit for Elm. Still, not going to get done any time soon.
  - twoquestions 10y ago
    Do you have a source for this? I'd be interested in their reasoning. You'd think Beam would be a very different compile target than JS, and it seems weird to make such a huge change without very good reason.
    - pmarreck 10y ago
      I think "massive concurrency" and "bulletproof uptimes" are pretty good reasons. Plus that would then allow Elm on both client and server. The Elm folks have been fairly buddy-buddy with the Elixir/Phoenix folks, so this doesn't surprise me
      - twoquestions 10y ago
        That sounds amazing. It makes my heart sing that a different VM than JVM or .Net is gaining more traction, and as a static types fan it makes me happy that a statically typed language may be getting on Beam.
    - knewter 10y ago
      I think the compile target is basically not a big problem, and there's been explicit work to make the Browser just one Platform. Also, see the `Process` module in the core docs for a hint of the future, regardless of where it lands (this would also work well for WebWorkers etc, and is handled right now by a naive scheduler). Concern over the compile target should be super low - if you've built a language of sorts, you should have a feel for how it's not that big of a deal to tweak the target.
jjnoakes 10y ago
I'm toying around with PureScript on node. It's not too bad.
jarcane 10y ago
Whereas after spending even a day with it I found myself wanting to run screaming back to Haskell. No typeclasses, no monads, more primitive pattern matching, no guards, use of massive nested elseif considered idiomatic ... Simple tasks wind up feeling tedious because so many of the standard tools and patterns of any other ML language are simple missing completely. The result feels like trying to work with one of those random toy Lisps people make in a weekend and throw up on Github. It frustrates me, because in theory I do like the concept of the Elm architecture, I love ML-style type systems, and I work with reactive programming every day in ClojureScript. But the language it's attached to is so incomplete that it quickly just becomes a pain.
- noelwelsh 10y ago
  That's exactly the dividing line I see in those who love Elm and those who don't. People coming from Ruby / JS backgrounds appreciate a modern type system and it isn't so different from languages they are used to that it is hard to get going. People already used to modern functional programming miss the abstractions they are used to that Elm doesn't provide. I find this really interesting. As a community we don't give enough attention to the sociological aspects of programming. You can see similar things in the adoption of languages like Go and Elixir.
  - deleted 10y ago
    [deleted]
  - lolive 10y ago
    (Sorry for my poor english but i need some clarification) Do you put Go, Elixir and Elm is the same bag, i.e langages a step further JS in term of abstraction, i.e langages easy to understand when you come from plain JS? And then, you put Purescript and Haskell in another bag, i.e langages with advanced abstractions absent from "casual" langages, i.e langages requiring a lot of effort to learn? Did I summarize your idea correctly?
    - a-saleh 10y ago
      I think understood the Elm/Haskell/Purescript, i.e: Javascript dev sees Elm and might think "Wow,a type-system and it is awesome, didn't expect that" Haskell dev sees Elm and might think "I am missing so many features with these types" and consider something else, probably pure-script, that has similar toolbelt. Not sure about the rest though.
jweir 10y ago
Have you looked at Reason from Facebook? It is a syntax for OCAML that is a bit simpler - https://facebook.github.io/reason/ https://facebook.github.io/reason/
TheWiseOne 10y ago
F# might be worth considering. You can also target JS by using a compiler like Fable (http://fsprojects.github.io/Fable/ http://fsprojects.github.io/Fable/) or FunScript (http://funscript.info/ http://funscript.info/).
dreamdu5t 10y ago
There is one: PureScript. You can build node apps with it and use it with webpack. There's even an Elm-like UI library https://github.com/alexmingoia/purescript-pux https://github.com/alexmingoia/purescript-pux
wyager 10y ago
Elm is essentially just Haskell with weaker type classes. If you can use Elm, I can't imagine why you'd have trouble using Haskell.
BenoitP 10y ago
I have been thinking about toying with JVM's Graal compiler (JIT and customizeable deopts for the price of an interpreter). But with a language that has few corner cases. I was thinking maybe regexes, or brainfuck, or QBasic. I'd just looove to try and put Elm on the JVM, but I just can't at the moment.

shados 10y ago

having types vs having good types is two totally different world. Elm's type system is really awesome. Interaction of simplicity and power. I kind of like to think of it as the Java to late 90s' C++, where "less is more" made it popular.

shrugger 10y ago

Scala.js is a lot of fun, have you considered using it? It's quite further along than Elm at this point.

not-much-io 10y ago
The reason I personally haven't looked at Scala (or Scala.js) is the OOP + FP approach. <personal understanding> Scala seems to want to please everyone, having all the tools at hand - Immutable and Mutable collections, Objects and enforced Pure Functions etc. That to me seems like a call for trouble in the community, a split between approaches to problem solving at a fundamental level. </personal understanding> And well one of the things that I love about Elm is the lack of needing to make too many choices because the language doesn't have too many complicated features and prioritises "One good lib over 5 decent libs" (though at this young stage what other option does it have). Clojurescript, Javascript and I'm betting Scala.js offer a lot of solutions to the same problem and/or have fancy language features that I am looking for an escape from. Just personally want to try going back to "less is more", to see what it is like. :)
- shrugger 10y ago
  Well, Scala was originally designed to complement a platform that encourages mutable data structures. When Scala was first getting started, Java didn't have anonymous functions yet, and it was a different time. Currently, Scala-Native is working on off-JVM Scala, Scala.js is already plenty capable of compiling to efficient JS, and when wasm lands, it'll probably manage that rather easily. Elm is a neat language, but I think it sort of presents too wide a divide. I have the same problem with Elm as I do with Typescript, Dart, and all of the other languages that recognize JS is a shit language, but just compile to it anyways. Scala is a VERY well-designed language, and FP/OOP isn't nearly as polarizing as it might seem. I'd recommend LearnXinY Scala, read a little bit and you might see how natural it actually is (excluding the obnoxious syntax for certain things) But yeah, JS has always been the crucial problem that needs to be solved. *.js is never going to solve it.
  - pmarreck 10y ago

agentgt 10y ago

For me it boils down to variant types (also known as Algebraic Data Types but I prefer the ML nomenclature) and the corresponding pattern matching that comes with it. This is IMO the major feature that makes FP languages so damn safe. Everyone talks about higher order functions and generic types but lots of languages have that.... the really good ones have ADTs. Oh what I would give to have ADTs in Java. I would stop using Exceptions for errors (not all exceptions are bad just most of them). I would stop using the annoying visitor pattern... That reminds me that I need to rexamine Derive4J

sanderjd 10y ago
I had a similar epiphany when I started using Rust. I hadn't really understood the power of ADTs, having only come across them in Haskell, until I saw them in an otherwise more familiar language, and it totally changed the way I think about things.
drudru11 10y ago
Have you looked at the Yeti language for the jvm?

zem 10y ago

you should enjoy this blog post on thomas leonard's experience porting 0install from python to ocaml: http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain/ http://roscidus.com/blog/blog/2014/02/13/ocaml-what-you-gain...