Right now, we are witnessing the comeback of the functional paradigm in software development. Companies are trying to see whether they can use languages such as Haskell, Clojure, Erlang in some parts of software and whether they perform better than object oriented approaches, e.g. Ruby.
Recently, some people from the Ruby community transferred to a language called Elixir (and Phoenix as web framework) which was actually created by Jose Valim, one of biggest contributors to the Rails framework. I thought that I will give it a try and learn a new way of thinking which comes with functional paradigm.
As far as Phoenix is concerned, it doesn’t use Ruby – it uses Elixir. Elixir is based on Erlang virtual machine called BEAM. Erlang was created in 70’s to automate telecom switches. Telecom switches devices have to work with millions of connections at once and they have to be highly fault-tolerant. Can you even imagine being unable to call an ambulance just because they the switches are currently under maintenance? Elixir can use all of Erlang’s goodies: the battle-proven per process garbage collector and the actor-based concurrency model using OTP (Open Telecom Platform). Fun fact: Akka, the actor concurrency library for Java and JVM, was created when Akka’s creator was unable to use Erlang because of a client’s requirements.
Let’s get straight down to programming and create a new Phoenix application. Elixir comes with a thing called mix. It’s similar to Bundler in Ruby: it controls project dependencies. Phoenix has also got rake, which is used for creating and launching previously programmed tasks. To create a new Phoenix project we can use generators – similar to Rails generators again – and just write in terminal:
mix phoenix.new blog_post_app
This will create a template for a new Phoenix project. Right after the execution of this task it will ask if we want to install dependencies with a mix deps.get task, which is analogical to a bundle install we have automated during rails new task in Rails ecosystem. Let’s look into the project structure:
It looks similar to Rails’ app folder, nonetheless it is different. Analogically to Django, all HTML goes to the templates folder. The views folder is used for view-related code, which is really awesome because it just allows out-of-the-box for separation of concerns. Controllers are really similar to those in Rails: models use more of a Data Mapper way instead of ActiveRecord. Channels are where Phoenix really shines – it gives us support for a persistent connection with a client (for example web socket). Erlang virtual machine processes are really small and because of that we can create a lot of them, which translates into creating a lot connections that can stay live. This is why WhatsApp and Facebook have their messaging platforms implemented in Erlang. In the next part of this series I will go straight to coding and try to create a sample blog app to see how it compares in development speed and also how different the functional approach is from its object-oriented counterpart.
I hope you’ve found my post useful. If you have any thoughts feel free to share them in the comments below.