Hacker News new | past | comments | ask | show | jobs | submit login
Phoenix 1.3.0 Released (phoenixframework.org)
437 points by chrismccord on July 28, 2017 | hide | past | favorite | 138 comments

For anyone curious about Phoenix and Elixir, I can sincerely recommend the following resources to get you started:

- Programming Phoenix by Chris McCord, Bruce Tate, and José Valim [1]

- The Little Elixir & OTP Guidebook by Benjamin Tan Wei Hao [2]

- Elixir in Action by Saša Jurić [3]

Phoenix initially attracted me to Elixir, I've stuck around for that and the OTP platform: pattern matching, process based concurrency (actor model), supervision, immutability, macros, and more.

"Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system." – Dave Thomas

[1] https://startlearningelixir.com/r/programming-phoenix

[2] https://startlearningelixir.com/r/the-little-elixir-and-otp-...

[3] https://startlearningelixir.com/r/elixir-in-action

Another great resource that was recently released is the Phoenix Inside Out series by Shankar: https://shankardevy.com/phoenix-book/

I just got it a few days ago and I'm about 30% into the first book. What I can say so far is that the author's approach resonates really well with me. Going through the book feels like sitting next to a colleague, who is introducing you to Phoenix and is really knowledgeable in the topic. The book is full of interesting tidbits and explanations about Phoenix internals without getting in the way. I also appreciate the TDD approach including both acceptance and unit testing. The most important thing for me though, is how Shankar condensed teaching Elixir into a single chapter. I have previously tried to study Elixir a few times with the intention of eventually getting into Phoenix but I always got overwhelmed by the OTP material. I didn't want to make the mistake of trying to learn Rails before being comfortable with Ruby again so I put off on learning Phoenix altogether. What Shankar has done is to dedicate one chapter to teach just enough Elixir for you to get started. This was perfect for what I needed and it was reassuring knowing exactly how much (or little) Elixir you need to know before diving into Phoenix.

If you have previous experience in another MVC framework and are interested in Phoenix I highly recommend this series (at least based on what I've read so far).

I should note that the current version of the book is targeting Phoenix v1.3.0-rc.2. Although Shankar has already made an announcement with the intention to update the book soon after the officially 1.3.0 release.

> If you have previous experience in another MVC framework and are interested in Phoenix I highly recommend this series (at least based on what I've read so far).

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.


I think you should be fine, especially considering you have some functional experience. In the second chapter of the book, the author goes over Elixir from scratch. By the end of the chapter you should have a working knowledge of the language. Even beyond this chapter, the author takes time to dissect and explain the more complicated looking code. It really does feel quite approachable to anyone with a few years of programming experience.

What is Garuda? Just a random title? A library/component in the Elixir ecosystem?

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

From the web site: "Create a mini-Phoenix framework using Elixir and Cowboy. What can be the best way to understand Phoenix than to create it yourself."

Garuda, I'm sure after googling you found the Wikipedia entry for it. It is just a play on words since Garuda, like Phoenix, is a type of mythical bird.

Ah, I found the Wikipedia entry, but didn't make the connection with Phoenix. Thanks!

Tomte, "Garuda" is not a random title. As you and others have guessed it, Garuda is a mythical bird in Indian mythology just like Phoenix being a mythical bird in Greek mythology. Since the book is about "Demystify Phoenix Internals & Rebuild Phoenix Clone", I have named it as Garuda.

I agree with you, I could have explained the book's content and its title a bit more clearer on my website. I will do it sometime soon.

Yeah, he should probably change the title from Garuda to something else (even 'Garuda: Learn Phoenix by building it yourself' is better).

This is the best Elixir material I've used: https://pragmaticstudio.com/elixir

You build you a simple HTTP server using Elixir and learn a lot of the core language and architecture choices when writing Elixir code. It doesn't pester you with this is an int, this is a string. You just start building this HTTP server out and learn about Elixir along the way.

Learned a lot from the pragmaticstudio resource as well and couldn't recommend it highly enough.

+1 on "The Little Elixir & OTP Guidebook". It's a generally good introduction to OTP, though the book has a lot more errors than I'm used to seeing (their github code differs without explanation from the code in the book at times, and sometimes one or the other won't run successfully).

Hey, are there already some tutorials / books for Phoenix 1.3? I found this [1], but it will be released in late december 2017. Any ideas / recommendations for the Phoenix 1.3? Folder structure and models (schemas) got changed quite a bit.

[1] https://www.amazon.com/Programming-Phoenix-1-3-Productive-Re...

You might want to add that all those book links have an Amazon referral link attached which (presumably?) points to you.

Elixir in Action is a bit outdated, no?

I read it a while ago, but I remember it being pretty useful.

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.

Just want to point out that Records are still part of the standard library, and can be important for integrating with Erlang code using records which you need to work with. Even though they are avoided in Elixir, because structs are better in every way, they are still alive and well in Erlang.

Thanks for the extra info.

For comparison, though, Dave Thomas' "Programming Elixir" doesn't even mention them.

We’ve been using Phoenix at my company in production for over a year now. So far the experience has been overwhelmingly positive, our team have totally come round to its adoption, our server costs have come down and our response times have gone down also.

Coming from Rails, the ecosystem isn’t quite there yet, but it is far more mature than rails’ was this early on.

The hardest thing for us has been deployment, but we’ve solved that internally, including giving back by building exrm_deb (it works with distillery too!) to compile the entire project into a Debian package.

If you haven’t already looked at Phoenix (and Ecto!) give it a try :)

Thats really neat...gonna check it out. Thanks for sharing. Here is the link for anyone else: https://github.com/johnhamelink/exrm_deb

Releases as a .deb?! Awesome!

You can have them as RPM as well if you are so inclined! https://github.com/smpallen99/exrm-rpm

I've been working professionally in Elixir/Phoenix for the past 4 months.

Summary: It's amazingly productive, pleasant to work with and simple.

Coming from a background spanning Python/Django, C#/.net and Node/Express I really believe it blows them out of the water.

Thank you for all the hardwork of the Phoenix team and the amazing community you've made.

As a .NET developer by day, I'm curious what you like about Elixir over C#/.NET? I have a copy of Elixir in Action on my nightstand, I just haven't had a chance to crack it open yet.

I wouldn't say I like things over C#/.NET (I love C# and use it for mobile/desktop devel, but I've never used it for web).. but I'll list some things I like about Elixir:

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?")
That's basically the equivalent of having a single say() function that then does a switch/case on the input.

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)
        render(conn, "success.json", msg: msg)
        {:error, msg} ->
          |> put_status(:unprocessable_entity)
          |> render("failure.json", msg: msg)
I love this feature. It makes code so much more readable and maintainable in my opinion.

I believe these are referred to Railway-Oriented Programming. I've seen several other examples for Elixir (incl. ones using macros), but by far this is the 'cleanest' syntax :)

Here's a similar construct in Scala:

    (for {
      user   <- currentUser(...)
      group  <- groups.fetchForUser(...)
      friend <- friendships.fetchFriend(...)
      member <- groups.addMember(...)
    } yield {
    }).recover {
      case e: Exception -> ...

Or you could just call it what it is: a monad

"Railway-Oriented Programming" is a lot more specific than "monad".

The Scala example, yes... The Elixir one? Is it actually a Monad? I figure it's simply destructuring + pattern matching (against the value of the first tuple value, :ok or :error atom).

To expand a bit more, it's not like Scala's `Either[T, U]` where we're limited to a pair of types, I think you can return other atom values (but use :ok and :error) as a convention.

Also, there is an Elixir library I'm using that's a closer in spirit to Scala's for-comprehension called `monadex`. Example below:

    result = success(comment_params)
             ~>> fn p  -> link_reply_to_id(p)  end
             ~>> fn p  -> create_changeset(p)  end
             ~>> fn cs -> assert_changeset(cs) end
             ~>> fn cs -> insert_changeset(cs) end

Wait is `with` a guard then?

Do-notation strikes again.

Pattern Matching makes it easy to write small, understandable code

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!

The Elixir pipe operator |> is the equivalent of the Clojure thread first macro ->, right?

Which is to say it's equivalent to function composition.

Yes it's syntactic sugar and for me personally harder to read but YMMV.

The directory reorganization is a good sign that Elixir/Phoenix are not simply rehashing Ruby/Rails for the sake of popularity but are willing to prioritize what makes the most sense for this particular language - and asking how they can improve upon what already exists.

I recently ported my app from 1.2->1.3 and moving away from Models to Contexts/Data was a simple transition that makes a lot of sense.

The `data` files (aka your new models) are basically where the schema for your model lives and the `context` (your models API) is the interface for your data.

For example when building a blog:

Instead of having User, Session, Post, and Comment models which contains your DB schema, business logic, and interfaces for getting/setting data all models directory ala Rails:

you instead create a namespace for each group of data:

And in your data file `lib/blog_app/blog/post.ex` for example, you'd keep just your schema defining the fields like "title, permalink, body, etc" and code to handle validations and virtual attributes.

Then in your context file `lib/blog_app/blog/blog.ex` you define the API that access your data. So from your controller instead of calling:

You now call:

It makes for a very logical structure for your MVC code.

Phoenix is great! I only wish there was one recommended way for authentication and authorization - there are so many [1] different libraries that I got stuck in researching the options - I am confused, do not know which one to use. What is your preferred way? I would like to avoid to implement every little detail on my own - to get security done right was the main reason for me using open source libraries.

It would be great if there was one official way to make it easier to implement app security with the framework. I feel that this is the only missing part in phoenix - but it is a very important one.

BTW: does anybody know some tool that generates a phoenix api from a json-schema? Thanks!

[0] https://github.com/h4cc/awesome-elixir#authentication

The beautiful thing about Phoenix framework is that there is no "one-true way" to do things. Rails is omakase, Phoenix is not, and that's a good thing.

You want the whole enchilada? Use Guardian.

Need oauth? Use ueberauth.

Just want email and password? Use comeonin to hash your password.

It's liberating to know exactly how your system works and that it's not hidden behind some magical blackbox like Devise.

A blackbox is not what I was asking for. I would be happy to find the features you described (and many more) in one (extensible) place like e.g. Phoenix.Security.

The problem with that approach is that imagine if Phoenix had a Phoenix.Security.sign_in function. How do you want to sign in?

With a cookie?

With a server-side session?

With a database session?

With an authentication token GET params?

With an authentication token in the header?

You make the choices for your specific use case and implement them using laser-focused, great packages. One system I built authenticates with an `authenticationToken` GET params, I look for that in a Plug, then assign the current_user to the conn object.

For non-api requests, I use plain old sessions.

For me the sweet spot is somewhere in between. If it just shipped with a decent auth module that would work for 90% of people, but that could also be easily replaced or extended if needed, that would be the best of both worlds.

Even rails doesn't ship with an auth module though. Lots of people use Devise and there is an equivalent for Elixir (Coherence)...but shipping with auth built in is an exploit waiting to happen IMO.

has_secure_password is not an "auth module". That's simply a handy function to handle a password attribute... which an actual auth module can make use of if it desired.

My mistake. :) was that added in 5?

Am I reading that right or is it just comparing an unencrypted string to the encrypted version?

It was added in 3.1 (http://guides.rubyonrails.org/3_1_release_notes.html) and uses bcrypt under the hood.

Laravel does, and their more batteries included approach is nice in my opinion

Guardian is annoying to setup but works for me. I just want something that generates JWT and takes a JWT.

I've been using Joken for that (JWT), just finished writing up some code that integrates with Auth0 and pulls in the signing certificate from the auth0 domain (.well-known/jwks.json).

The closest clone of Devise I found for Phoenix is Coherence https://github.com/smpallen99/coherence

If you're coming from a Rails background, you'll find Coherence[1] similar to Devise.

However, I was recently in need of implementing authentication for more than two models (Buyer, Seller) and that's where I hit a roadblock with these Devise-like libraries. Just by chance I found a really good, well designed library which I use in production as of now. The author is also the author of many other famous libraries in Phoenix-verse (Comeonin, for example). The library is called Phauxth. Check it out:


[1] https://github.com/smpallen99/coherence

I agree with you. Most of the web apps required authentication with email + social(google, fb twitter, github). In most of the rails app people would be using Devise + omniauth and these both works seamlessly and very easy to integrate.

As of now there are no libraries available to implement above functionality easily for Phoenix framework. For me also this is one of the main reason to go ahead with Elixir + Phoenix

Auth : Guardian

I'm spending all my free time with Phoenix. I come from a Rails, Laravel, Django and a bit of .NET Core background. So far I am extremely impressed. I'm surprised it has not been adopted by that many folks in production.

Shhh, the first rule of Phoenix Club is that you don't tell everyone that it is the best web stack out there.

Far, far too late for that here in HN :-)

I'm a django guy. I have no experience with functional programming.

What would a transition to phoenix + elixir look like for me?

You'll have a phase of disorientation where you'll be wishing you had x feature in Django and the reverse where you'll wish you had y feature in Phoenix/Elixir.

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?"

Could you give some examples of 'neat' things that needed to keep going no matter what on django (thus switching to Phoenix)

I should have said Python instead of Django.

The problem is that I was/still am a rookie of a programmer. I could not wrap my head around async in Python. I just wasn't getting it. I had a nagging sense that it was going to fail in the middle of the night and there was nothing I could do about it.

So, enter Elixir, which actually has a syntax that is kind of close to Python. It made immediate sense. If you want to do something that can cause the program to fail, do it in a process and send a message back with the result. If the program spawning the process fails, the supervisor will restart it!

Sorry - back to your question - and this will probably disatisfy you, but the answer is that everything was neat. It was just simple CRUD stuff, but doing it in Python didn't feel "robust" enough.

I'm fully aware that my reasons are superficial, but the way Elixir works has made me way more confident as a programmer.

This isn't your fault. Python doesn't get the asynchronous stuff particularly right, nor does it make it as straightforward as it should. I've moved to Elixir and one of my employers has moved to Go as a direct result of Python's concurrency model (and the hilariously needless and recondite primitives attached). Your reasons aren't particularly superficial; I'd pick the Actor model over systemd and uWSGI for anything critical!

Very satisfying , thanks !

As a Ruby/Rails guy, here's my experience(summary):

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.

It's more Rails than Django but once you've seen one MVC framework you've seen them all.

I'd suggest:


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.

Thanks for the link. One thing I hated about Rails when I tried it was the level of magic involved. Does Phoenix suffer from that at all?

Phoenix works within existing Elixir constructs like macros and modules, so it keeps a lot of the nice interfaces of Rails without the magic, how things work is pretty straightforward.

It is worth stating that the way Erlang/Elixir manage processes is completely different than most other languages and that has to be grokked at some point. Thankfully the framework abstracts a lot of that.

The Elixir and Phoenix docs are also pretty good. They're not Django-level (what is), but they're good.

Phoenix 1.3.0 really helps you understand that you are just making an Elixir app with some additional features. I don't think there is as much "magic" as Rails.

There's almost no magic in Phoenix, it's modular from the start and is really just a collection of libraries held together by some mix tasks to help you structure stuff.

Phoenix is much more straightforward and explicit but macros are used a lot in both Phoenix and the Elixir standard library. I think most of the macros are fine but opinions vary widely on that.

Something isn't magical if you understand the underlying concept/convention.

I tend to think of "magic" as meaning fragile, indirect coupling; for example "magic numbers" at the start of files, which are only meaningful if the consuming application has a corresponding pattern in its database.

Or sets of things which only work if given in a particular order. Or unrelated functionalities which interfere with each other due to implementation details. And so on.

In other words, leaky abstractions where thinking in terms of the concept has so many edge cases that it's easier to think in terms of the implementation instead. Or conventions which can only be used via memorisation, trial and error, stack overflow and reading the source (often this is due to shoehorning things into language models which aren't amenable; e.g. all of the things aspect oriented programming tries to do)

Everything above the machine level is magic (the computer is doing stuff behind the scenes for you, abstracting away from all the unnecessary detail).

Go into it with the attitude of 'deferal of gratitude'. In other words it might look painful for a while but when various things click you get your holy s moments and you'll never go back. I've worked in a lot of java, php, python, c# etc frameworks and there are very specific reasons this is near always better long term. A lot of it comes back to elixir simply solving the correct problems. Learn elixir using the elixir lang site guides and then jump into phoenix using their official guides. Eventually you'll experience the upsides and versatility

By correct you mean that Elixir solves problems differently than java, php, python, etc. and you found this more appealing over time, which may or may not be the case for someone else.

Or are you making a stronger claim that language X is better than Y, at least when it comes to web dev?

No I don't mean it in a way that is subjective. It does depend on person to person because of factors in their knowledge and situation, history etc etc, but elixir lives in a world that the others don't. Making a language that plays on the erlang vm and has complete access to OTP was a good solve. Other languages haven't been able to replicate OTP despite attempts (and they likely won't). It's not better for everything and the language isn't somehow obviuosly better, it just solved the right problem if you want easy web scale that doesn't do things like drop connections when you release or have a difficult concurrency model. Functional programming is a grind at first but it's a good fit for this world and elixir is more accessable day to day than erlang. I have way more experience with PHP but there are limitations there that can't be solved. So I would say that both your points apply, I am making the claim that X is better than Y because of core value reasons, but that doesn't mean that economically other languages don't make sense for web programming. I still make new projects in PHP and Python because of existing infra at work and others that can't/won't learn elixir and co. We'll just be making something slightly inferior and not be building tools for a more pleasant future, but it still makes money for the biz and isn't terrible

You mean `deferral of gratification`. I couldn't help myself.

hah! thanks honestly. I need to bring up this term more often than you'd think and without thinking about it got it wrong probably almost every time

I've used both and honestly it probably wouldn't change much. Unless you're building an application that deals with tons of persistent connections and websockets there aren't really that many advantages. The Python ecosystem is also much, much bigger than the Erlang and Elixir ecosystem and it has far more mature libraries.

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.

The difference between Elixir/Erlang and a statically typed functional language is that it's built for distribution.

In a distributed system where machines register on a cluster and messages are passed constantly across isolated heaps, processes and entire machines transparently all of the assumed protections of a static type system break down. You can't enforce static types across a cluster anymore than you can across a JSON requests to somebody else's API without a lot of extra overhead.

Static types are essentially contracts and in order to enforce a contract like that on a cluster of different machines that would mean you'd have to exchange contracts everytime a new machine joined the cluster...for all modules and functions...with every machine on the cluster. And then you have to determine how to handle contract violations.

Clustered message passing operates more like request routing in that regard. Send to this machine, to this module, to a function named this, with this arity, that matches this pattern.

The Elixir gradual typing approach balances this reality extremely well in my opinion. You get type checking if you want it and can specify it in more detail...but it won't promise something that it can't guarantee across the cluster, across deploys and across changes.

I beg to differ. FP with Clojure is pure joy. Spec, which is due out soon with 1.9, is also the next best thing to static typing. Some would even say it's better.

>> I'm surprised it has not been adopted by that many folks in production.

I'm surprised that it's used in production at all. It's based on a new language that is years behind all the others in terms of available third-party libraries and modules.

Does the language lack some maturity? Sure. But you don't have to use pure elixir for everything. You can leverage most Erlang packages. Phoenix is hosted on Cowboy[0] which is a mature, battle tested web server written in Erlang.

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

All libraries from Erlang can be used as-is, so the gap is much smaller than you might expect. Phoenix itself is based on an Erlang web server.

Really excited to see this out. I've been learning Elixir and Phoenix with the 1.3rc and have really been enjoying it!

I'm a fan of Contexts myself as that is typically how I architect apps on mobile as well. I like having everything separated more explicitly and testable individually and Contexts seem to promote that in a really nice way.


In the past few weeks:

- Erlang/OTP 20 released,

- Elixir 1.5 released

And Cowboy 2.0 is in Release Candidate phase.

Exciting times.

Gonna do phoenix for a side project.

I'm just a bystander reading about erlang and elixir for awhile. Did web dev in php and a little bit of nodejs.

But I think what you guys doing are great. I'm glad Elixir and Phoenix came about it really helps drive the language into a field (web dev) and get people to notice.

And that one implementation of figuring out how people is log off or not that is in Phoenix was really sweet when you presented it.

Would you suggest to choose Elixir / Phoenix for an api for a startup? Is it too risky now, or good enough + very attractive?

Just me personally, I probably wouldn't do it in anything else... Not that there aren't some other good options out there depending on your background. I just prefer Elixir, I know it scales in both maintenance and performance (the former being the more difficult goal in my mind) I think the market is growing such that finding engineers who a) have experience, or b) want experience with it, won't be a real problem. I can tackle software and hardware problems alike, there are good options for integrating native code when performance counts, and in general I consider it to be the safest option available to me.

I'm biased as my company (Bleacher Report) uses it extensively for this exact purpose but yes: do it. It's great.

It's used by fairly big projects/Companies bet365, Bleacher Report, New Relic,Discord, PagerDuty, Puppet labs, FireEye etc.

I had not heard New Relic was using it

I use it for my own small startup + my work uses it as well. Couldn't recommend it hard enough. Elixir 1.5 (just released) improves Developer Experience and makes things a little easier to debug.

Highly recommended, but as always ignore the hype/recommendations and do your own research.

I will. The only risk is finding devs - there are too few that know elixir. Not hard to switch though ;)

Yes, you won't regret it.

Jump in, the more the merrier!

I actually love the domain driven work done in this release. I think it was a bold move from the team and breaks them even further away from Rails on EVM that people tend to think.

I have been bit so many times with trying to figure out where to put things like authentication/registration in a traditional MVC rails like app.

I've always been intrigued by Phoenix/Elixir but I was worried it may just be a fad. Seems like it's had solid growth over the last couple years though, so I may end up diving into it over the weekend.

We are using Elixir and Phoenix. Its amazbalz. The properties of the erlang VM (100k processes, individually garbage collected etc) are going to make it a killer platform. (edited)

Are there any "here be dragons" for Phoenix? Does it play well with legacy systems? Support for different protocols, etc.

YMMV on protocols, just depends on what you're looking for. Most reasonable protocols you'd want are supportable. The only time I've been left scratching my head was trying to get the VM running on a SOCKS proxy, which I think probably speaks more to my lack of familiarity with doing so (though in the source of this I found that the native SOCKS libraries were removed some time ago.

We're using it at a client as a kind of nexus of all our legacy systems, in fact.

I don't think Elixir has production-level support for gRPC which is a bit of a deal-breaker for me.

There seem to be plenty of gRPC libraries for Erlang though, according to a quick googling.

Great news! Been waiting for this so I could tinker and then make a pitch to my office where I think it's an ideal fit.

Does Phoenix 1.3.0 fully support Elixir 1.5? I keep getting warnings when compiling since I upgraded to Elixir 1.5.

It does. You may also need to upgrade your mix dependencies, I'm sure many of their authors are busy fixing the deprecation warnings as I type

I use Phoenix with all my newer projects. The performance is stellar. I single-handedly was able to create what many startups out there have built with 100s of thousands of engineers[1] in a short period of time. This may be possible with Rails too, but then, I found a lot of things are much more convenient to get done in Phoenix than in Rails - For example, Contexts (nested models), Routes, etc.

When I started with Phoenix I was anxious that the experience was going to be just like when I first tried out Play/Scala, but no. To my surprise, my experience was fantastic. Truly, this framework allows you to focus on your business problems rather than fighting with configurations/conventions.

One of the best decisions the team has made is introducing the concept of contexts from DDD[2]. Initially, I was pretty confused, but now, I simply cannot imagine myself going back once that I've understood it. It's basically breaking down your business into smaller tiny modules, like I've done in [1]. The other thing I love about Phoenix is the concept of umbrella applications. I'm not sure if Rails has an equivalent, but I think this alone is worth exploring Phoenix for.

I don't even have micro-services in my architecture yet, but because of these patterns, I'll be able to break out and scale my application if I require to, in the future.

Phoenix has proven to me that it can not only scale performance-wise, but also architecture-wise. Last time I tried developing [1], it was in PHP and I had to hire 5 devs to get it done..6 months later and we still weren't done. However, in just a matter of weeks, I was able to finish a complete working prototype of this mammoth application, with UI and frontend. As for my production setup, I use Docker + AppEngine (using a custom VM) and it has served me really well. The performance is top notch and everything works so flawless.

As for the language itself, I really love Elixir. I simply cannot imagine going back. It really forces you to think differently about your code. Last time I tried to learn a functional language, it was Scala - also a beautiful language on top of the JVM. But, the problem is, it's so academic in the sense that even a good book on scala had 400+ pages. Some of them had 700+ pages. But Elixir isn't like that, you can pick up the language in a matter of weeks (YMMV, it took me 2) AND build a project in no time.

For Elixir, if you're coming from a Ruby background, you'll be able to pick it up fairly easy. However, you will find it challenging when you hit a situation where you would have used a traditional for loop, but in Elixir, you would be forced to re-architect your code. And that's a good thing.

[1] https://news.ycombinator.com/item?id=14785209

[2] https://martinfowler.com/bliki/BoundedContext.html

Interesting. I've been trying to decide which language to learn next. Between Scala, elixir, and haskell at the moment. Was leaning Scala, but all the praise here is starting to convince me to go elixir. What problems did you run into with Scala?

In Scala, there are many ways to write a function. I wish I can share some code snippets, but, I'll just summarize for the sake of simplicity:

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


> 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

While it is possible to look at source code in Ruby/Rails, in practice for me (even after a few years of production ruby experience) it was extremely painful to look at any number of libraries due to the amount of redirection and implicit state, and monkey patching. But Elixir has (almost always) been VERY easy to follow, sometimes the code is just so simple.

It's truly amazing when you see the numbers yourself, as Elixir/Phoenix produces some wicked TTFB(time to first byte) speed and concurrent performances you can't get from other languages.

I wouldn't be surprised to see one elixir server replacing 5x - 10x servers.

Been following Phoenix for a while now. It looks amazing! One small complaint: the lack of code highlighting in the documentation really bugs me.

How are people hosting their Phoenix projects? I'm used to Heroku or Laravel Forge. I don't really want to mess too much with servers.

Me neither. Devops is a hat I wasn't interested in wearing.

Which is why I tried Gigalixir[1] and never looked back. It's sort of like Heroku for Phoenix/Elixir, but without the daily restarts and with hot upgrades and the ability to run a BEAM cluster. Jes (owner) has been super responsive and deploys are trivial... just like I like it.

Also got Postgres running in google cloud (a new offering!) and that's worked great as well.

Sparkpost for an email API and Timber.io for cloud logs have also been stellar. Sweet dashboards.

You get a lot at the free tier on these.

[1] https://www.gigalixir.com

Phoenix works well on Heroku: https://hexdocs.pm/phoenix/heroku.html

I also want to try gigalixir which has a free tier: https://gigalixir.com/

Note that Heroku has some drawbacks with regards to Elixir:

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

In a datacenter on bare metal :-)

I also work on a number of side projects with coworkers and we host those in Heroku. Can't really speak to how well that'd work if they were more than just side projects, but it works for us.

Does anyone have any favorite open-source Phoenix codebases?

hexpm the package manager website is open source:


Firestorm is another:


I had to switch to the home page and go below the fold to figure out what Phoenix was (a web framework in Elixir).

Quote interesting release, many useful features. `action_fallback` looks really nice. Contexts ... not so much imo

> Contexts ... not so much imo

I'll prefix my comment by saying I'm someone who is more on the sysadmin side of the scale of things. My code isn't pretty, but it generally works well enough to get the job done. I'm learning (probably the most important thing, I guess).

Contexts are one of things that I felt the same about. Until I tried really using them, rather than stressing over whether or not I was using them properly.

I made the mistake of trying to think of them as microservices, which bogged me down and for my purposes was complete overkill. I've now reached a kind of happy medium, which I've realised that I really should have already been using. I've kinda realised I suck at api design. And for that I'm very thankful to the phoenix team, because it feels like I'm learning.

Contexts are in practice pretty nice, and you don't have to use them. I've found that in my own work with 1.3.rc.*, the contexts describe an area of the system and help enforce some separation of concerns. That said, you're free to build everything in one context.

I have an example where context works well for me.

I have built an app[0], the app allow user to submit links, either using our web ui or via a bot.

When using web ui, they have to login, hence we associate the links with that user. The bot is different, everyone submit via the post share the same `Bot` account.

In other words, the process of inserting a link from web ui or via bot is a bit different. Without context, I would use different module or some branch code to distinct between them. I think context solves that nicely for me.


[0] https://one.betterdev.link which is an extra version of https://betterdev.link/

Contexts are just the default now. Nothing is preventing you from doing things the old way, or from using them in 1.2 without upgrading. If you can think of a better architecture that doesn't involve contexts, then that should absolutely be what you're doing.

I love contexts!

But if you don't, that's cool too. There are mix tasks for using the older style generators and mix tasks for the newer context style generators. Use whichever you prefer.

Contexts might not like nice, but they really are in practice.

Oh finally! I've been using RC for quite a while now. Glad it is out.

Awesome work Chris, thanks for everything you and the team are doing!

Thanks for the hard work! Looking for to upgrade

How is it better than F# and Akka.NET?

I wouldn't say "better". Like any other framework, many things have to be weighed. In the case of F#, it's a fantastic language with a fantastic runtime. It is still "windows only"* for the moment though. Akka (and yes, I realize that you mentioned .NET) is also very good in its varieties. Scala being one of the ones that I've actually used. I believe where the sweet-spot is for Elixir, in general is that Rubyists will feel mostly at home. The language itself is just very, very nice. Phoenix continues this by copying some of the nice ideas from Rails. But again, It's not better than the language and tech that you mentioned, but it fits a certain swath of developers. I wouldn't recommend someone who is well versed in F# with Akka.NET drop what they're doing to migrate.

*Yes, I'm aware of Mono, but I've been completely unhappy with my experience using it.

Why not turn the question around. Since this is a post about Elixir & Phoenix, why do you think it's not better than F# and Akka.NET?

Awesome, nice work!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact