1. 12
  1.  

  2. 4

    I gotta say, this would make me awfully nervous. I tend to agree with the dictum that you should be including at most one new and sexy technology in your stack at any point. The hype on Elixir and Elm is super high right now—that’s not to say that either one of them is overhyped, or undeserving of its attention, but if I read about starting one new project where essentially the entire stack for both the front and backend is brand new, I’m going to start wondering whether these decisions were made for engineering reasons or because the author wanted a chance to play with some new and exciting tools.

    1. 4

      I’d put Elm in the “new and hip tech” bucket but you should remember that Elixir is based on decades-old Erlang/OTP experience. If you really want to reduce Elixir to a short sentence, it’s cleaned up, syntactic sugar over Erlang with macros (among other goodies).

      Elixir is hyped, sure, but at least its claims about fault tolerance and distribution have historical proof because they’re Erlang’s claims.

      Something that stands out to me about the Elixir/Elm pairings is that people focus on Elm’s types as a major point yet use a dynamic language for the backend.

      1. 4

        I’d put Elm in the “new and hip tech” bucket

        I would argue that while Elm is still currently in that bucket, it is start to leave. The language is becoming more stable on the whole, and the ideas it promotes have already spread to almost every other frontend framework available. If you’re writing Redux, you’re writing Elm without types. With regards to the types, Elm uses a basic type system which has existed in MLs for decades. At this point, there is little that Elm introduces as hip - instead, it is more the coagulation of a few very popular ideas elsewhere. Elm’s type system has historical proof because of this. The Elm architecture has been popular in concurrency groups for a long time, too.

        Something that stands out to me about the Elixir/Elm pairings is that people focus on Elm’s types as a major point yet use a dynamic language for the backend.

        Agreed. Elixir’s typespecs just don’t match up with the types-as-a-feature of Elm. To me, the biggest selling point of Elixir is the build tooling that helps simplify getting started with Erlang. Rebar is dead, long live rebar. Honestly though, if I got to choose the backend for a new production job, I would probably choose Haskell. I’d rather have a proper type system than not. This is not necessarily true for other Elm users - I see a lot of them coming from Rails or JS backgrounds, and Elm’s type system is often the first proper type system they’ve used.

        1. 1

          Fair enough, I do think Elm is a safe choice nowadays (I have a friend who works at NRI ). Like @zdsmith I do see it “hyped up” a lot so I got the wrong impression. Thanks for the explanation.

      2. 3

        Usually, I’d agree with you. Especially when looking at the JS world. But many of the interesting concepts in Elm and Elixir have one significant advantage over “hip.js”: It’s very hard to screw up your code. The lack of this feature in Coffeescript and ES7, for example, makes it easy to misinterpret or half-heartedly apply solutions one doesn’t understand, making it hard as hell to maintain the software afterwards.

        But proper typing, pure functions, good error messages, and time travelling debuggers are all things that are hard to misuse and generally lead to better code. These languages teach better programming, IMO.

        1. 0

          whether these decisions were made for engineering reasons or because the author wanted a chance to play with some new and exciting tools.

          This is basically a mass-hallucination in the Elixir community. For some reason the Elm meme has become deeply embedded in the brain stem of some Elixir devs, not for any good reason it would seem.

        2. 3

          Phoenix looks pretty great. In fact all the Elixir stuff is quite exciting. In particular, the fact of even starting to have a proper pop at Unicode is admirably ballsy - and having just done a bunch of websocket stuff for a client in node.js, Phoenix’s channels look really enticing. I just wish, from my own totally personal perspective, that if people are starting to dig the BEAM so much then maybe all this flourish could happen with Erlang, because Ruby syntax makes my eyes itch and all the Ruby/Rails “community” stuff I watched from afar over several years made me run a freakin' MILE and Elixir’s variable rebinding hurts my brain and now when I search for Erlang libs for X there’s all these amazing-looking Elixir libs that I can’t use without (presumably) doing a bunch of gymnastics or (at least) learning a bunch of Ruby-like syntax that I don’t even, and I know I’m old and tired and probably obsolete and you can’t teach an old dog new tricks but … Erlang syntax seems jus' FINE to me. Hey ho.

          1. 1

            If you don’t like variable rebinding, don’t use it – I don’t, and nothing bad happened to me.

            Calling Elixir from Erlang is also pretty simple in the cases where the function’s input arguments are basic Erlang types (atoms, binaries, maps, keyword lists, numbers, charlists, etc) – check out the details. Basically:

            SomeModule.some_func(:cool, %{val: 1}) in Elixir becomes

            'Elixir.SomeModule':some_func(cool, #{val => 1}) in Erlang.

            In any case, Erlang had about fifteen years of open-source life to catch on before Elixir came to be. I don’t see Erlang gaining traction like Elixir has, for better or worse. Luckily, we Elixir devs aren’t shy about using Erlang libraries, so you can keep on producing libs in Erlang and if they’re good, we’ll use ‘em. :)

          2. 1

            Elm still looks completely foreign to me, no matter how many articles I read about it :(

            1. 2

              You just gotta start writing code.