I've been following Phoenix for awhile now and it's one of the first "shiny new things" that I'm genuinely impressed by...especially coming from Rails. Why?
- Out of the box, it solves the architectural performance problem that inhibits every Rails project by using the ErlangVM
- It's a fairly easy migration path for someone that has a Ruby/web-mvc background
- It's API-ready out of the box, which means connecting to devices, other services, etc is built into it's design
- Since it's functional programming by design, it means data manipulation is inherent to developing applications
Same here - the strongest argument for me are the performance benefits. I really like working in Rails but Ruby's general performance and memory handling tends to be a issue - when you run into problems it's hard to find the root.
Looking forward to diving into Phoenix and Elixir.
I honestly don't understand why Ruby developers are all so excited about Elixir/Phoenix.
Don't hear me wrong, I think Elixir is an amazing language and I love using it, but it has nothing to do with Ruby, the paradigm is completely different. It makes me think that the only reason Ruby devs are so into it is just because the syntax is similar, which make them seem a little... shallow I guess.
I think Erlang just wasn't really on my radar before. I didn't know much about it and kind of just associated it with phone systems and didn't consider it for web.
Elixir just came up on my radar and I started seeing a lot of smart people looking at it and Erlang, and so I did too. Now I kind of don't want to go back to Ruby. Part of it is that I like Elixir's syntax better than Ruby's, but mostly it's everything else.
Ruby isn't very good at concurrency, so people making Rails apps have to move things to other services (sometimes in totally different languages) in order to get around this. As I've learned more about OTP I find that I can spin up different 'services' in the form of GenServers that are running inside the same VM, use supervisors to handle the inevitable crashes that will occur, and because the entire system is in the same language/VM it's a little easier to test. So far it all just feels less like some Frankenstein that's getting stitched together. :)
Phoenix is nice too, but a lot of its niceness and power really comes from things lower than it in the stack: OTP, BEAM, Cowboy, Ecto, and mix. I really like Ecto so far, it feels more natural to me than ActiveRecord once I've gotten the hang of it, although it still has places where it is obvious that it's not quite as mature. One thing that Phoenix provides which is really nice (although I haven't made much use of yet) are the channels.
I work with Ruby all the time, but the skin-deep similarity in syntax isn't at all why I like Elixir. I'm excited about Elixir because, like Ruby, it makes programming fun; even though the two languages are fundamentally different.
I'm not a rubyist but it could be that their jaded with the current state of Ruby and constant performance struggles with Rails. Elixir has a similar community that's focused on testing, tooling, and quality.
However I agree, very little Ruby syntax, just def & end for the most part.
> I honestly don't understand why Ruby developers are all so excited about Elixir/Phoenix.
Perhaps the history of Ruby uptake explains it? My feeling is many of these 'Ruby' developers started as Rails developers. Rails did cool stuff, but it had they fanboy/hype around it that only Apple usually garner.
I wonder if now Ruby is established, has lost its excitement, and problems are encountered by users day-to-day, Elixir looks like the next magic bullet? I.e. they are predisposed to being attracted to the noise [and NodeJS didn't attract them all because of...??]
I've nothing against Ruby or Rails, but I did not appreciate the single-minded hype and excitement around one piece of technology which wasn't flawless.
I can relate to that yes. What kept me away from RoR is this strange community that seemed to stubbornly refused to look into anything else, believing that their technology was the silver bullet. Maybe I was wrong, but that's the feeling I got. I have to say, the performance issues in Ruby always were a bit problem to me.
I would hate to see the same thing happen with Elixir which, I believe, can become an amazing technology and finally help give Erlang the recognition it deserves.
I just find the Erlang style bizarre. I know it's a great language but I'm really don't see myself going the extra mile. I think Django is a good mid level framework that is good enough performance-wise for most cases. I'm now learning Play and Scala to take cover those high demand edge cases.
The notion that Erlang is bizarre but Scala isn't is a particularly intriguing notion...but that's a different rant.
I suppose the concurrency model of Erlang is a departure from The Way Things Are, but I'd argue that's a good thing. The JVM doesn't offer much fundamentally different in terms of the concurrency model than Ruby and Python. It certainly performs orders of magnitudes better, but it's still subject to a lot of the same issues: you have a pool of threads running your http service, and when you exhaust that pool then you have outages. And stopping the world for GC is enormously problematic. Erlang takes care of all that in an extremely elegant way.
Also it doesn't take minutes (!!!) to compile an Elixir (or Erlang) program. Developer happiness is often overlooked (Scala being the worst offender in my experience) and Elixir really hits that out of the park.
I've been comparing Erlang, Elixir, and Scala lately, and Scala seems to have both a nicer syntax and a nicer feature set than the former two.
Scala is definitely C++-esque in being a bloated language. And it lets developers commit utter horrors. But if you stay away from those horrors (mostly new operators and DSLs) and don't use them yourself, it seems like a very nice and elegant language. You get the same functional programming and actor concurrency you would get form Erlang and Elixir.
Elixir feels like the functional language a ruby programmer might create. When you're programming in it, it feels like 90% of the power of ruby with 10% of the features. Instead of being constraining, I find the relative lack of features (compared to ruby) liberating.
Elixir also has a supremely powerful and elegant macro capability that lets you build really powerful DSLs. For example, chunks of the language are written as Elixir macros -- the if 'keyword', for instance. As a programmer, you have full access to the very same macro system. Writing an unless 'expression' isn't even that hard.
phoenix's use of Elixir's macro system is part of why phoenix can feel so much like rails.
And yes, from the fragments I've seen of Erlang, the two are completely different. What Elixir wants from Erlang is primarily the VM and the OTP libraries.
If you've seen Erlang and it scares you off Elixir, you've got it all wrong.
What do you mean by that? If you mean Elixir borrows some of Erlang's esoteric data structures, like lists, then yes, you are correct. However, the language itself doesn't look anything like Erlang. It resembles Ruby more than anything else.
I know they're not common in modern HLLs since we have magic do-everything array ADTs, but I find it kind of hilarious to describe (singly-)linked lists as "esoteric."
Personally, I enjoy having (really cheap) lists around, and wish more HLLs had them as one of their fundamental, low-level abstractions. There's something extremely satisfying about accumulating elements backward by consing, and then reversing at the end. I'm always worried in Ruby/Python that push()ing elements onto an Array might do all sorts of stupid re-allocations at just the wrong time; lists, on the other hand, have extremely obvious time-space complexities for all their operations.
That's something that can be said about all the Erlang ADTs, now that I think about it—each one has been carefully considered such that you can guess the time/space complexity for each operation and be correct. Erlang (and Elixir) also has a policy that if two ADTs both have an operation with the same semantics, but the two operations have different complexities, then the two operations will get different names—which is amazing for making bad ideas (like trying to do random-access on a list) obvious.
(And really, while we're on the subject, it's tuples that are the weird Erlang type. As handy as they are as an underlying implementation for records et al, there isn't really much theoretical basis for having a set of N fixed-size non-enumerable product types, each with integer-indexed, untyped slots.)
Big fan of Phoenix and the Elixir community. Everyone has been extremely welcoming and Chris himself has given me some advice when I'm stuck. Very happy with this framework and I look forward to seeing how the Elixir community grows.
To newcomers: learn Plug first. I created a web server using just Plug and it's been a blast. At first it was difficult to wrap my head around how things were supposed to work, but as time went on Plug's flexibility really started to show; I basically fell in love with Elixir! Now I've moved on to Phoenix (which is built on top of Plug) and it's been a much easier ride than diving into Phoenix head first.
I can totally agree - I've been on their Slack channel and it's nothing but friendly and welcoming. It's kind of like the MINASWAN (Matz is Nice And So We Are Nice) idea in Ruby, but since the Elixir community is even smaller, it's even more important.
I second the recommendation to build something with Plug first. Phoenix was my first dip into Elixir, but I quickly found that I didn't know wtf was going on. I built a little API thing that accesses sheets via the Smartsheet API, and decided to do that from scratch. Started with a GenServer to do the API access, and then added Plug. This showed me how all of the pieces fit together without starting from even a Plug template. Very useful exercise!
We use Phoenix and Elixir a lot at Bleacher Report and it's great.
However there is very little information out there on how to improve performance. For example - we saw out of the box performance for a simple data parser being better with Symphony than Phoenix (but both were way better than Rails).
It's not a catch all performance booster, even on things you would expect it would be (this was an API that pulled lots of data concurrently from other sources to build the API).
It IS a huge improvement over rails however. José Valim is a great guy and we were lucky enough to have him talk about both here at BR. Plugs alone are a lovely architectural touch and it's worth people checking out the system just from a widening your perspective type of deal, even if you won't be using it in production.
For Phoenix, the main constraints in performance are usually around configuration like the size of your database pool or if protocols are being consolidated. Once those are tweaked, you are usually good to go!
Generally speaking though, Erlang in Anger is a great (and free) resource and Observer is a fantastic tool. When we made Phoenix handle 2 million connections, observer was all we needed to find the bottlenecks. The fix was then to optimize ETS or introduce a pool of processes.
If performance is not what you expect, feel free to ping me or Chris. I personally enjoy doing this kind of work. :)
Can't say for sure, but in PHP some modules are writted in C and optimized, it might be that you are seeing that. Overall PHP due to number of things, how collections are processed etc is very slow.
Elixir/Phoenix is pretty much consistently fast and encourages practices that I believe will make your app really fast.
I still think Whisper has the biggest Phoenix deployment in terms of traffic. It's a huge part of what makes our web development easy because our backend is all Erlang. Thanks Chris and José (and everyone else) for such a great set of tools.
I'm not actually there anymore, but I know they were moving a lot of stuff to Elixir and Phoenix and some of my friends have given a few talks on it... I went to the last two Elixirconf's but haven't really used it much professionally myself yet. Another media company called Inverse is using Phoenix and Elixir for a lot of their infrastructure. They're still small, but growing rapidly. inverse.com
This release includes the optional addition of GetText, which allows Internationalization (i18n) :)
Very happy to see one of my major qualms be resolved so quickly! Lots of potential for Phoenix. Currently using Rails, and I assume I will be for the next year or two, after that I'm pretty dead-set on switching over to Phoenix.
Last time i tried to dig into elixir/erlang ecosystem, i tried to have a look at how deployment was supposed to be made with those platform, and only found at least 3 years old articles and debates on how to do it.
Could someone point me at a description of the current best practice ?
Edit : seems like phoenix documentation has a section explaining just that pretty well. Wonder why i couldn't find anything as clear elsewhere...
I've been using Elixir and Phoenix lately. It's out-of-the-box defaults are insanely good, though certainly some parts of the language are tricky to get used to.
Is there a realistic opensource example app? Curious to see how it looks like.
Ruby syntax is a big minus for me and afaik Erlang is not strongly typed. While obviously syntax is a personal preference, I'm quite interested to hear from Phoenix users how it compares to Go/Haskell/Rust/etc, especially in cases where I don't need real-time.
You can't use Dialyzer to give you the more-or-less iron-clad type safety you get in C++ or Java, but you can use it to get warned about many type errors that might have otherwise gone unnoticed.
Semi-OT but I really think that there shouldn't be any more software products with the name/codename Phoenix EVER AGAIN ... Had no idea what this was without looking.
Can recall several projects named "Phoenix" and none of them really gained notoriety... And please, not "Firebird"
12 years (almost 13) after a certain browser had to change its name because of trademarks, it's interesting to see that Phoenix Technologies doesn't seem to care about this one.
Maybe it's partly that I live in Phoenix, AZ... but I've seen a lot of companies/software that use "Phoenix" in the name to the point it's really a meaningless name to me.
Though in looking into it, it does seem pretty cool.
I built a side project in Phoenix (http://www.peergym.com) and was impressed how fast the community has adopted to creating solutions - everything from authentication to geolocation is covered.
If you're curious to try Phoenix but feel like the ecosystem is too bare bones, you should check out awesome-elixir, which grows every day!
I been working on my Elixir skills and Phoenix, and let me tell you how fantastic it is, it is pleasure to use Phoenix, as someone coming from Rails, it has a lot of good parts. Channels... are awesome. I love it and can't wait to see what will future bring.
And performance, that we have plenty.
FYI, I am day to day using Rails and have few Meteor projects, but I can see my future in Phoenix on both accounts.
Weird how when you click on google groups link on top, instead of Phoenix announcement, it takes you to all announcements :)
Is this what its like to be old, to first think this is going to be a link to an archived message from 2002 about the Phoenix browser? Also, to starting worrying whether they're going to have to rename this thing just like Firefox had to.
I have been reading through Learn You Some Erlang because I had to do a presentation on Erlang for a class. As soon as I finish it and understand it and OTP, I am moving to Elixir and possibly Phoenix. Both are going to have a great future.
The 2 million connection journey they have is quite impressive, though it would've been nicer if they made those clients actually do something other than just connect to the server.
The test was specifically around max channel clients and pubsub subscribers, but we'd like to do more tests in other areas when we can get access to a lot of hardware again. To be clear the clients were mostly idle, but we did broadcast messages to all 2M subscribers, which is quite a bit of work with 2M messages being sent down the wire in 1-3s.
As a Pythonista, I'm envious that Rubyists have this excellent thing called Elixir to migrate to. I would jump wholesale to Elixir if I could fulfill all my various use cases with it. But at one point I may start using Phoenix for my web stuff.
Definitely keeping my eye on it, and I think these guys (Elixir in particular) nailed the right implementation.
If I had a language I could wish for, a BEAM VM language with Pythonic syntax would be it.
I have actually tried to a make Elixir space sensitive but I was not comfortable on how it played out with the macro system. You can still see though some Python influences, like heredocs, doc tests, the System module, etc.
Still, past the initial syntax similarities with Ruby, it is a very different language than both Ruby and Python. You should definitely give it a try :)
An invite directly from the head honcho himself! Thanks Jose, I will do so.
My dream language was basically Elixir, another BEAM VM language but Pythonic but called something like 'Hydra' to play off the Python theme. Envisioning a multiheaded snake fits right in with the Erlang actor theme.
But, why reinvent the wheel when you guys already have something similar enough. I'll for sure reserve some time to dive in.
I am a Pythonista myself and I use Elixir at work. Even though Elixir looks like Ruby, it has very little in common with Ruby. Elixir's syntax is very simple and it's very easy to migrate from Ruby/Python. Please try it, you may actually like it more than Python :)
Node.js and Elixir/Erlang have two different models of concurrent programming. Node has its single threaded event loop and Elixir uses the Actor model. Practically that means that your code is split into many small individual actors or routines that are highly concurrent (and parallelizable) and work together by speaking to each other.
Some specific advantages of Elixir's model of concurrency along with it's implementation is:
* BEAM (Elixir/Erlang's VM) creates a schedulers for each core in your machine. Processes are efficiently loaded across each scheduler. This means that your application can easily make use of and scale with the cores of your computer.
* Processes are lightweight. These processes are much smaller in size than an operating system process or thread. It isn't uncommon for an Elixir application to have hundreds of thousands of these lightweight processes. In a way, an Elixir application is almost like a micro service architecture, each process does a small little thing and communicates with other processes to work together.
* Processes can be preempted. A node block can yield on IO operations, but what if a block is CPU intensive. The other blocks waiting in the queue will starve. In BEAM the scheduler can preempt a process if it's taking to long and let other processes have some time on the CPU.
* Processes can crash and thats ok. Since processes don't share memory, they can crash without corrupting the memory of other processes. Elixir/Erlang also has a great library (OTP) that deals with handling how processes crash. If a process crashes it can be restarted without having to restart your whole application. One of Erlang's flagship applications was quoted to have nine nines uptime. That's 99.9999999% uptime. That's not because it didn't have errors, but because the application knows how to deal with those errors without having to bring the whole application down.
Elixir or Erlang provide truly parallel or even distributed code execution. node.js is just concurrent, so it falls flat when doing heavy CPU work. And no, clustering node.js isn't even remotely comparable for anything but trivial API services.
- Out of the box, it solves the architectural performance problem that inhibits every Rails project by using the ErlangVM
- It's a fairly easy migration path for someone that has a Ruby/web-mvc background
- It's API-ready out of the box, which means connecting to devices, other services, etc is built into it's design
- Since it's functional programming by design, it means data manipulation is inherent to developing applications
I'm excited to see the adoption go up.