Programming in Elixir with the Phoenix Framework
gogogarrett.sexy
Programming in Elixir with the Phoenix Framework
1–10 of 28 posts
Re: Programming in Elixir with the Phoenix Framework
#2Nice writeup. I hadn't looked at Phoenix yet.
It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them is a bloated piece of nonsense that doesn't make good use of C#'s strengths. We should avoid making Elixir a Ruby-on-Erlang when it has the potential to be so much more.
I haven't figured out yet to what extent Phoenix does this, but this blog post highlights some things that make me wonder.
For instance, the router confuses me. Is there any point in making an explicit router over just splitting the URL by "/" into a list and then just pattern matching on that?
e.g.
def get(["users", user], _params) do
# show stuff
end
def post(["users"], _params) do
# store stuff
end
def get([], _params) do
# show root page
end
Re: Programming in Elixir with the Phoenix Framework
#3Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
From the little that I know of Elixir, the overloaded methods with pattern matching on the arguments is Elixir-ish.
Re: Programming in Elixir with the Phoenix Framework
#4Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
I'm not a Phoenix pro, but I believe it is actually doing something similar to what you're proposing.
http://slides.com/chrismccord/rise-of-the-phoenix#/7
Here is a slidedeck from the creator (@chris_mccord) explaining a bit more about the router. It looks to be doing simply pattern matching.
Re: Programming in Elixir with the Phoenix Framework
#5Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
> We should avoid making Elixir a Ruby-on-Erlang when it has the potential to be so much more.
Elixir is fool-proof from turning it into a "Ruby on Erlang" simply because it embraces and improves on Erlang's programming model. Some libraries are ported over from Ruby. But there are also libraries ported from other languages and libraries that have been written for Elixir specifically.
Just a heads up: please don't make hasty generalisations based on a single project you've seen.
Re: Programming in Elixir with the Phoenix Framework
#6Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
From the little that I know of Elixir, the overloaded methods with pattern matching on the arguments is Elixir-ish.
Indeed, and that's not what the blog post's router code does.
Re: Programming in Elixir with the Phoenix Framework
#7Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
We had a lot of conversations about this and it was a somewhat common topic during ElixirConf (http://www.confreaks.com/events/elixirconf2014). On my keynote I addressed exactly your concerns: it is fine to do "X in Elixir", which is a very helpful learning exercise, but remember to revisit it later, otherwise you will have a project that misuses or does not fully uses this new environment.
Dynamo (https://github.com/dynamo/dynamo) is such an example. It was one of the first web frameworks that showed up for Elixir and it got a lot of things wrong. However, out of the lessons learned, we got:
* The configuration layer that comes with Elixir. Elixir has the concept of applications (the same as Erlang/OTP applications) which you can be stopped and started as a unit. So the whole mechanism on how you define applications and configure them is defined by the language/runtime and consequently that is one area where Phoenix is considerably different than Rails.
* I absolutely hated the view layer in Dynamo (which attempted to be too Rails like and did not fit Elixir). Chris got the lessons learned from that and provided an absolute great view layer for Phoenix, where you have the concept of views (modules) and templates (embedded into those modules). Dispatching to views is done with pattern matching (similar to your example above). There aren't any global helpers and the views are easily testable in isolation.
* Plug (https://github.com/elixir-lang/plug) also came out of Dynamo. It has the same goals as Rack (because you can't really diverge from the goals): a specification for web servers and an API for connecting applications. However, implementation wise, it is very different than Rack. Rack applications usually build on top of a middleware stack which receives a request environment, passing through all layers, and then returns a response that once again goes through all layers. This approach is what makes Rack uncomfortable for chunking, connection upgrades and so on. In Plug, the plug stack is one-way, you only get the connection (instead of a request and response) because we assume a response can be sent through the connection at any point during the stack (disclaimer: I am both Rack and Plug committer).
The list could go on. :) Our build tool, Mix (http://elixir-lang.org/docs/mix), is inspired on Clojure's lein. The most used database layer, Ecto (https://github.com/elixir-lang/ecto), borrows a lot from LINQ (hard to have an ORM when you don't have objects!). There are even some other smaller examples in Phoenix like the current attempts to remove the singular/plural nouns that we see a lot in Rails and, in my opinion, causes a lot of confusion.
Re: Programming in Elixir with the Phoenix Framework
#8Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
> We should avoid making Elixir a Ruby-on-Erlang when it has the potential to be so much more. Elixir is fool-proof from turning it into a "Ruby on Erlang" simply because it embraces and improves on Erlang's programming model. Some libraries are ported over from Ruby. But there are also libraries ported from other languages and libraries that have been written for Elixir specifically. Just a heads up: please don't ma…
When I wrote "we should avoid making Elixir a Ruby-on-Erlang", i meant exactly that. I didn't mean the sugar-coated American oh my god how can I say this without being direct version of "we're making Elixir a Ruby-on-Erlang and this has to stop".
Sorry if you were offended, but I think you're reading more in my comment than there is.
Elixir is young enough that it can go many directions and it depends on the early libraries and frameworks what that will be, and we should be able to discuss that. I ended my comment with a question precisely because I don't actually know enough about Phoenix to judge it.
Re: Programming in Elixir with the Phoenix Framework
#9Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
Phoenix creator here. Please take a look at my ElixirConf presentation where I exactly address your concerns. We're very much not out to replicate Rails and we are leveraging Elixir's strengths. As Dave Thomas said "Why replicate when you can innovate?". I very much agree. Our realtime Channel layer shows this off. That said, we have borrowed a few ideas from Rails where they make sense. I think Rails got a lot more right than it got wrong, but our goals are to go well beyond and redefine what you think of as a "web framework" traditionally. We're aiming for a "highly connected web framework" for devices, whether that's your browser, iPhone, Android, or smart toaster. For example, we already have a native Swift client for our Channel layer. With respect to the Router example, our Router DSL does a number of things like defining named route helpers, i.e.:
`Router.users_path(:show, 123)`
We also have a `resources` macro similar to Rails style that wires up half a dozen or so resftul endpoints that you'd otherwise have to roll by hand. This would be particularly tedious in your example once you started nesting resources. The Router also serves as the entry point to the Plug middleware stack where we wire up some essential middleware and connection metadata.
My ElixrConf talk gives a full overview of the framework and some of the more interesting features not addressed by a CRUD app: http://www.confreaks.com/videos/4132-elixirconf2014-rise-of-...
Re: Programming in Elixir with the Phoenix Framework
#10Nice writeup. I hadn't looked at Phoenix yet. It seems that many Elixir people come from Ruby. One thing we should be wary of is making shallow ports of Ruby concepts into Elixir, when there's much more elegant approaches available. We, software engineers, have a tendency of doing this: for example, there's a whole bucketload of C# libraries that have Java roots (NHibernate, Spring.NET), and every single one of them…
We had a lot of conversations about this and it was a somewhat common topic during ElixirConf ( http://www.confreaks.com/events/elixirconf2014 ). On my keynote I addressed exactly your concerns: it is fine to do "X in Elixir", which is a very helpful learning exercise, but remember to revisit it later, otherwise you will have a project that misuses or does not fully uses this new environment. Dynamo ( https://github.…
Cool, thanks for that bit of history. I did not know about Dynamo, and I'm impressed by how willingly it was dismissed when learned lessons arrived. The early-adopting C# guys who ported Hibernate over weren't so insightful.
Great that you're pushing this attitude! I see that maybe I worry too much.