We had a lot of conversations about this and it was a somewhat common topic during ElixirConf (http://www.confreaks.com/events/elixirconf2014 http://www.confrea

We had a lot of conversations about this and it was a somewhat common topic during ElixirConf (http://www.confreaks.com/events/elixirconf2014 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 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 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 http://elixir-lang.org/docs/mix), is inspired on Clojure's lein. The most used database layer, Ecto (https://github.com/elixir-lang/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.