It’s not often I get excited about programming languages since meeting Ruby in 2015.

Way before that, drowning in misery of writing university course works in Java, has pushed me away from development. Ruby’s freedom and expressiveness was what pulled me back, and it’s style has kept me in.

I was on the lookout for another language to expand my tooling, and came across a few, such as Crystal, Pyhton, Elixir. But what’s the point with just another Object Oriented language I thought.

So, choosing Elixir was a no-brainer, and I will finally taste some of that juicy concurrent abilities with functional code base.

I can say that a week in, I am already happy with my decision. However, the reason is not mostly associated with my understanding of possibilities, but more because how welcoming the language is alongside following best practices.

Starting with Ruby, all I cared was to get something done in fast and stylish way.

Starting with Elixir, I took a different approach, not because I chose, but because I have been instructed.

Let’s go through a few points on how Elixir welcomes newcomers to the language.

Great language documentation and resources

Being a fairly new language, I did not expect that there was such huge amount of quality resources for Elixir. Official documentation itself is gold. This, alongside with Elixir School was all I needed to get going with the language.

Documentation as a first class citizen

I can not stress the importance of documenting code base enough. However, in most languages you get a feeling of it being an optional thing, thus mostly ignored, or not followed consistently.

Writing and generating documentation is a breeze in Elixir due to built in tooling. You can even write docs which will be automatically added to your test suite

Built in code formatter

Not all code bases implement static analyzers on time, and then it just becomes a pain to catch up. (I wrote a little post about how you can bring static code analysis at a later stage to your Ruby projects.)

There are loads of code bases that don’t even know about the existence of consistent formatting.

As trivial as it may seem, it absolutely isn’t. Consistent styling is not optional, and Elixir helps us to avoid that by providing us with built in code formatter from start.

Type specs, when you need them

Hahaha, I didn’t imagine that one day that I would like to write typespecs again. However, working with mostly financial tools/money, I would rather prefer extra clarity when I need it.

For this we can use type specs over function definitions when we need it.

  @doc """
    Authenticates using OAuth.

    If succesful, returns {:ok, %Client{}}, else {:error, %ApiError{}}.
  """
  @spec authenticate(String.t(), String.t()) :: {atom, Client.t() | ApiError.t()}
  def authenticate(grant_type \\ "password", scope \\ "forintegration") do
    params = %{
      grant_type: grant_type,
      scope: scope,
      username: Application.get_env(:banco_bs2, :account).user,
      password: Application.get_env(:banco_bs2, :account).pass
    }

    case HTTPoison.post("#{@base_url <> @auth_endpoint}", url_encoded(params), headers()) do
      {:ok, %Response{status_code: 200, body: body}} ->
        handle_success(Jason.decode!(body))

      {:ok, response} ->
        handle_error(response)

      {:error, %Error{reason: reason}} ->
        {:error, %ApiError{message: "Connection error occured: #{reason}"}}
    end
  end

Your code will still compile with type issues as Elixir is not a statically typed language, however, it will help you to have more clarity when writing code.

You may use Dialyzer or other tools to have it statically checked as well.

Erlang interoperability

It’s great to have access to mature Erlang ecosystem libraries within Elixir. I was a little confused in it’s usage in the beginning because you access Erlang libraries as :symbols.

Long way ahead |>

I am amazed how after a single week, even as a beginner, I can start to write maintainable and readable code in a new language and paradigm.

Let’s see where this all goes. In no means, I will be writing less Ruby, but more Elixir alongside.

See you around on Slack channel!