ecto

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.