Phoenix 1.1 Released
groups.google.com
groups.google.com
- 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.
Looking forward to diving into Phoenix and Elixir.
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.)
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.
It's odd at first, but has a few things going for it:
* Its rules are consistent.
* There are few keywords and symbols.
* Once you understand it, you see that pattern matching on function heads or case statements is exactly the same as if/else statements.
* Its standard library contains code that does a lot of the low-to-mid-level stuff you find yourself doing.
* OTP provides nice templates for server-ish things and FSMs, as well as some nice conventions that get followed by a lot of Erlang software.
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.
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.
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.
However I agree, very little Ruby syntax, just def & end for the most part.
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.
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 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.
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.
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.
Good practices all round.
Elixir/Phoenix is pretty much consistently fast and encourages practices that I believe will make your app really fast.
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. :)
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.
Looking forward to it, keep up the good work!
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...
But MAN is phoenix great.
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.
http://erlang.org/pipermail/erlang-questions/2015-December/0...
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.
Can recall several projects named "Phoenix" and none of them really gained notoriety... And please, not "Firebird"
Though in looking into it, it does seem pretty cool.
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 :)
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.
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.
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 :)
But, why reinvent the wheel when you guys already have something similar enough. I'll for sure reserve some time to dive in.
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.
Hope that helps.