Phoenix 1.3.0 Released

Some of the elixir bits are now out of date. (eg. it still has a section on Records)

But it touched on a lot of OTP topics that were missing from other places.

(this was before Benjamin Tan's book was finished)

At the time I remember Elixir in Action really made me finally understand the OTP concepts.

Do you need Elixir experiences too?

I've done MVC and have some functional experiences.

I've seen this book but wasn't sure if it was for me and decided to do exercism's elixir exercises before buying this book.

thanks

It's a strange way to sell a book, when neither the web site selling the book nor googling seem to enlighten me.

The Concurrency Model is simple to the point where creating a whole pubsub system to handle events, push out notifications, and handles backpressure can be done in < 100 lines with no additional datastores or frameworks.

Finally the pipe operator is like C#'s LINQ statements but with so much more power and flexibility, hard to explain but I highly recommend cracking open that book on your nightstand!

Erlang's concurrency model is amazing. It's like having micro-microservices running inside your virtual machine. And you can distribute across nodes. Nothing else really has this kind of thing.

Pattern matching is beautiful and it's easy to use. Other languages have this too, so it's not like this is unique. This is one of my favorite things though; you can destructure things, you can pattern match inside a function using case, and you can pattern match on functions themselves like:

    def say("Hi"), do: IO.puts("Hello")
    def say("Bye"), do: IO.puts("Goodbye")
    def say(_msg), do: IO.puts("Where am I?")

And a more recent addition to the language is "with". This is fantastic, it's one of my favorite things now. Usually you might have code that sets a variable from something, checks to make sure it's valid, sets another variable, checks to make sure it's valid, etc, etc... until finally you're function is ready to actually perform its purpose. Any of those checks might cause it to exit early or to switch paths. So Elixir has this "with" feature that looks sort of like this:

    def create(conn, %{"id" => group_id, "friend_id" => friend_id}) do
      with {:ok, user} <- current_user(conn, groups: [memberships: [:user, :group]]),
           {:ok, group} <- Groups.fetch_for_user(user, group_id),
           {:ok, friend} <- Friendship.fetch_friend(user, friend_id),
           {:ok, member} <- Groups.add_member(group, friend)
      do
        render(conn, "success.json", msg: msg)
      else
        {:error, msg} ->
          conn
          |> put_status(:unprocessable_entity)
          |> render("failure.json", msg: msg)
      end
    end

I'd suggest:

https://pragprog.com/book/phoenix/programming-phoenix

In structure it reminds me a lot of the very first Rails book co-authored by DHH. It's a good way to get into the language/framework.

The thing I really miss from Django is the admin scaffolding. Phoenix just isn't there. In practice, you could continue to use Django as a front-end.

I moved away from Django when the recurring question of "this is neat, but how do I make it keep going no matter what?"

I came to Ruby from Java, I wrote Ruby code like Java code at the start, it runs, but it is bad, once I really learned to write Ruby code it became a billion times better.

Same thing happened to Elixir, my first few lines of Elixir were very similar to Ruby, similar syntax makes this possible, but I missed the real gains from Elixir this way.

There are quite a few functional programming concepts to learn, but once I finally clicked what pattern matching was all about Elixir programming went from enjoyable to amazing, if you can work functional programming concepts your way you can do a lot.

That said, don't worry about it unless it is critical for your job, do your code, once all the concepts click in it gets way better, spend some time with pure Elixir, it pays off just as much as it pays to a Rails developer to understand what Ruby is all about.

If you really want to learn a functional programming language I'd strongly suggest looking at Haskell, Ocaml or F#. Functional programming only really starts to shine with a good static type system and dialyzer simply doesn't cut it.

[0] https://github.com/ninenines/cowboy

1) Functions have different forms and even nomenclature based on how many parameters they accept, how they are represented, etc.

2) Scala still has OO, which means it needs to carry a lot of baggage. The breadth of Scala's nomenclature combined with OO will take you a long way to learn the language.

3) Scala still runs on JVM which means you need to learn some of the JVM concepts if you'll be using it in prod. If you're from a Rails background, this is completely a new arena, because this is usually the Java guys' arena.

4) I wanted to be able to simply open up the source code and be able to understand what's happening. This was possible in Ruby/Rails, and ultra easy to do in Phoenix/Elixir, but painful in Play/Scala. IF you open up the source code of a Play! framework project, there's code so succinct that you would need to be strong with the language's understanding to get the full picture. Case class, implicit, etc., just to cite a few. In Elixir/Phoenix, it's just modules and it's just simple, yet elegant.

5) That being said, it's still good to learn Scala because there are tons of libraries out there with special use cases which you can use Scala for - It's still a good strongly typed language to build a robust project on. IF I remember correctly, David Pollak mentioned in his book that he'd written an app in Scala that ran for years without any problems.

As for Haskell, I read this somewhere - "Haskell is nice and all, but it's no Erlang." Since Erlang also has a bit of a learning curve, the next best alternative is Elixir.

P.S, - languages should be chosen based on one's own philosophy and in this case, Elixir strongly resonates with my own philosophy and all this is just my own opinion on why I chose it :)

Cheers.

1) Daily restarts, which kill any app-side state such as a cache or ETS table

2) Can't take advantage of any clustering

3) Can't do hot upgrades