I am happy to announce the fastest and most complete Elixir version yet was just released. In case you don’t remember, Elixir is a programming language implemented on top of the Erlang VM with charming syntax, method dispatching and metaprogramming awesomeness. By running on the Erlang VM, Elixir provides a good alternative to build robust and concurrent systems.

The version v0.3.0 released today provides improvements to the standard library, enhanced method dispatching, anonymous methods and some performance optimizations. You can learn more by taking a look at the changelog.

Most of the improvements on this release came as requirements from Frankie. Frankie is a Sinatra like clone running on Elixir and works as follows:

module MyApp
  mixin Frankie::App
 
  get "/hello_world", def
    "Hello World"
  end
end
 
Frankie.run 'mochiweb, MyApp

In Ruby, Sinatra uses instance_eval to evaluate the block in the application instance context. As we don’t (and won’t) have instance_eval in Elixir, we can achieve the same functionality with anonymous methods. Anonymous methods are the same as regular methods except they don’t need a name. Frankie keeps a reference to the method which later is invoked with MyApp instance.

The performance improvements were also targeted to Frankie. When running on Elixir v0.2.0, Frankie can handle 5500req/s on my machine, but on version v0.3.0, it reaches 9000req/s. You can find more information and a comparison with other Sinatra-like libraries on this gist.

Finally, Elixir built-in test suite called ExUnit now runs test cases in parallel for faster results, the methods respond_to?, eval and remove_ivar were added and a new module called Timer, equivalent to Erlang’s timer, was added in order to provide better benchmarking tools.

What is next?

There is still a lot to be done in Elixir and I feel that releases are getting stable enough for more people to jump in and start having fun! If you want to help (yes!), there are several ways to improve the language, here are a few:

• Help organizing the documentation. The README is quite complete but people complain that it would be better if it was organized into sections. The README would then be just a quick start guide;
• If web development is your thing, you can help us by improving ExBridge and Frankie;
• Build something cool, share it with us and send bug reports.

Most of all, now we also have an IRC channel on freenode called #elixir-lang where you can hangout, discuss, give feedback and ask questions. You can start now by joining and following the first steps in the README. So, what are you waiting for?

Tags: elixir, frankie, sinatra
Posted in English | 1 Comment »

I’m pleased to say Elixir v0.2.0 is finally out. In case you missed, Elixir provides a charming syntax and method dispatching on top of Erlang VM. There is a CHANGELOG, but keep reading if you are interested in more details.

Assignments

When Elixir was first released, it followed the footsteps of Erlang when it came to assignments. This meant that a variable could not be assigned more than once:

x = 1
% This would raise an exception
x = 2

At first, I imagined this restriction was to avoid side effects but it actually has its roots in lambda-calculus. In Math, equations like x = x + 1 have no satisfiable solution. Does this mean multiple assignments are side effects free? It depends.

If you have global variables, multiple assignments can clearly introduce side effects. Two threads (or Erlang/Elixir processes) could try to modify the same global variable, leading to race conditions. Another situation where multiple assignments could introduce side effects is in closures. But only if closures are able to change their original binding, as in Ruby:

x = 1
(lambda { |y| x = y }).call(2)
x #=> 2

This could easily lead to race conditions if you are sharing a lambda between threads. Each time a thread executes the lambda, it could change the value of a variable, modifying the behavior of other threads that depend on it.

That said, in order to have sane multiple assignment in Elixir, we cannot have global variables nor mutable closures, but that is fine as we don’t have them in Erlang anyway. The following is then possible in Elixir v0.2.0:

x = 1
x = 2
x = x + 1

If you want to match with the value of x, you can use:

x = 1
% Now this raises an exception
~x = 2

Updating variables

Structures are immutable in Elixir. This adds an important syntax restriction that can be easily explained using some Ruby code:

class Person
  def name
    @name
  end
 
  def name(value)
    @name = value
  end
end
 
person = Person.new
person.name("José")
person.name #=> "José"

In the example above, we define a class called Person, initialize it and set the instance name. The name definition happens by changing the value of the instance variable @name. The code above is modifying the existing structure in place.

In Elixir, however, all structure are immutable. All modifications in one structure needs to necessarily create a new structure. This means that the instance variable assignment expression @name = value should actually return a new structure. As it would be awkward for such expression to return a new structure, it was disallowed in the first Elixir release. Particularly, if you wanted to update an structure, you had to use the update_ivar method. The code above would be written in Elixir as:

module Person
  def name
    @name
  end

  def name(value)
    update_ivar 'name, value
  end
end

person = #Person()
person.name("José")
person.name %=> "José"

This was explicitly a temporary workaround until Elixir provided a better syntax as assigning instance variables is a quite common task. Well, no more workarounds! In Elixir v0.2.0, you can assign instance variables using @() as follow:

module Person
  def name
    @name
  end

  def name(value)
    % Update the attribute given by the atom/symbol 'name
    @('name, value)
  end
end

Compilation and scripting mode

In its first release, Elixir was a completely scripted language. For performance, Elixir modules were compiled to Erlang VM right after its definition but this was affecting load time. The language runtime was taking 1.2 seconds to boot, as it had to parse and compile the basic modules in the standard library. Another issue with the scripting approach is that it would make hot code swapping impossible to implement.

Due to all these aspects, Elixir now has an explicit compilation time. The current release ships with elixirc available to compile files. With an explicit compilation step, Elixir now takes 0.2 seconds to boot and hot code swapping is possible (although needs to be better supported). Even more, Elixir now uses Erlang code server instead of its own, which also introduces the benefit of autoload. Modules are automatically autoloaded, without a need for explicit requires.

One nice aspect of Elixir compilation is that it depends on runtime. It allows us to have all the meta-programming benefits existent in Ruby (which allow you to go much beyond Erlang macros). For example, consider the file counter.ex below:

module Counter
  dict = { 'one: 1, 'two: 2, 'three: 3 }
  dict.each do (key, value)
    module_eval "def #{key}; #{value}; end"
  end
end

When we compile the file with elixirc counter.ex -o ., it will execute the code above and dynamically define the methods one, two and three which will return its respective integer values. The compiled Counter module would look exactly if it was defined as follows:

module Counter
  def one
    1
  end

  def two
    2
  end

  def three
    3
  end
end

You can verify it by running iex (interactive Elixir):

> Counter.one
1
> Counter.two
2
> Counter.three
3

In other words, the compilation step simply saves a snapshot of the module after all the code is executed. With all this benefits in mind, the official way to distribute Elixir code is through compiled code, enjoying both improved performance and autoload capabilities.

However, a scripting language proves to be very convenient in several occasions and it is also available in Elixir. It will run exactly as a compiled file, except modules will need to be parsed and compiled every time you run your script. You can read more about it in the README!

Other changes

There were also several smaller changes and contributions from other developers around the world. New modules were added to the standard library, new methods, and so forth. Also, Elixir had several improvements on performance and smaller ones are still to come in next releases. Finally, expect some new projects that depend on Elixir coming around the corner. Don’t forget to checkout the CHANGELOG.

If you want to join the Elixir boat, now is a great opportunity! Grab the README, try it out and starting hacking away!

Tags: elixir, hot code swap
Posted in English | 3 Comments »

At the beginning of this month I have published a screencast about Elixir. For those who missed it, Elixir aims to provide simple Object Orientation and charming syntax on top of Erlang.

Based on my strong Ruby background, I was asked several times and finally decided to write a blog post about why Rubists should play with Elixir. Granted that most of Elixir’s syntax and a few features like method missing and module eval comes from Ruby, allowing you to achieve similar features when it comes to meta programming. However, Elixir is definitely closer to Erlang than anything else. Single assignment variables, immutability, easy communication between processes, lists, tuples, binaries and OTP behaviors are all available in Elixir. Therefore, you will be able to learn a lot by using Elixir, here are the things I have enjoyed the most learning:

Pattern matching

Pattern matching is one of the features I enjoy the most in functional programming. They provide an easy to extract information from a data structure. For instance, in Elixir, you would write:

[first, second] = [1,2]
first % => 1
second % => 2

You could definitely write something similar using Ruby assignment operator, but the gain in pattern matching comes from the fact you can use them in method signatures and, if a method signature does not match one specific pattern, the next method is tried. For instance, here is a method that iterates through a list of strings and print them:

module Printer
  % This pattern matches a list with at least one element.
  % The first element of the list is assigned to h, the remaining
  % is assigned to tail.
  def print([head|tail])
    IO.puts head
    print(tail) % Recursively calls print with the tail
  end

  % Eventually the list will be empty and the method above
  % won't match, causing this one to match instead.
  def print([])
    % Do nothing, we are done printing items
  end
end

Printer.print ["foo", "bar", "baz"]

Another cool example is a recursive method that checks if a list is a prefix of another list:

module Prefix
  % Iterate both lists. Check if the first element is equal then call itself again.
  % If the first element (i) is not equal, it won't match this method.
  def is?([i|prefix], [i|list]) is?(prefix, list); end

  % If the prefix is empty, is because everything matched, so return true.
  def is?([], _list) true; end

  % Else, return false
  def is?(_prefix, _list); false; end
end

Prefix.is?([1,2,3], [1,2,3,4,5]) % => true
Prefix.is?([0,1,2], [1,2,3,4,5]) % => false

Finally, pattern matching allows us to easily have key-value args, one of the features planned to Ruby 2.0. This examples comes straight from Elixir code (notice that symbols in Elixir start with a single quote instead of colon):

module Record
  def retrieve(name, 'from: file)
    % Implementation ...
  end
end

The fact that neither Elixir nor Erlang provides conditional loops like while forces you to think differently and use pattern matching in different occasions. Thinking differently about a problem that you are frequently solving in Ruby and coming up with a completely different solution is in general a very insightful and enjoying process.

Also, notice that both Elixir and Erlang do tail call optimization, so the methods above will perform nicely while you could get huge stack traces if you implemented such methods in Ruby in a similar fashion.

Single assignment variables and immutability

What I haven’t showed in the example above is that variables in Erlang are single assignment, therefore, the following will raise an error:

[first, second] = [1,2]
first = 10

The above raises a bad match error because, since a value was already assigned to first, the second expressions first = 10 is actually comparing 1 to 10, which obviously fails. The fact variables are assigned just once is what allows us to implement our prefix method above, ensuring the value assigned to i matches in both lists.

Also, both in Elixir and Erlang, objects/data structures cannot be modified in place. They are immutable. Every modification generates a new object/data structure. Immutability removes the shared state internal to the language (you still have shared state if you have to do external operations) and play a key role on Erlang’s and Elixir’s concurrency.

Personally, I have found immutability to be a blessing and a curse at the same time. Mutability is not commonly an issue when working with Rails applications, but while working on Rails itself and other gems, we need to be frequently thinking about mutability. Sometimes you pass an object (like a hash or an array) to a method that modifies it in place and then you have to spend some time tracking how that new element ended up in your object.

When working in Elixir, since everything is immutable, I don’t need to worry about such cases and yes, it feels good! It feels like going from C to Java and then I suddenly don’t need to worry about memory management. However, such benefit comes with an obvious downside that some code just becomes more verbose.

To show this downside, consider a possible create action for PostsController similar to Rails, but where we have rewritten it to consider both immutability and single assignment variables:

def create
  post0 = Post.new(params[:post])
  post1 = post0.set(:published, false)
  post2 = post1.save

  if post2.persisted?
    redirect_to post2
  else
    render :new
  end
end

In such cases, the ORM could likely provided better APIs, but that is a pattern that would repeat over and over again. For instance, modifying the response cookies would require an explicit change in the response object:

response1 = response.cookies.set "tracker_code", "123456"

In any case, just working with a language that provides immutability and single assignment variables is worth the experience. You will learn a lot by trying it out that I could ever mention in a blog post. As pattern matching, it frequently forces you to handle problems through a different perspective which is extremely challenging and rewarding.

UPDATE: As some pointed out in the comments, Elixir can remove single assignment and still play properly with Erlang’s foundations. For this reason, Elixir now allows you to assign to the same variable more than once and has more flexible rules related to the variable scope (similar to Ruby) when compared to Erlang.

Communication between processes

Pattern matching, single assignment variables and immutability provides a good foundation for communication between processes. If you are interested to learn more about this one and see all these things working together, watch the screencast from previous week!

A different Object Model

Elixir has a different Object Model from Ruby. The Object Model is prototype-based like Javascript, in the sense there are no classes, but it is also different from Javascript and Self in the sense an object can still dictate how its children is going to look like, not necessarily being an exact copy from the parent. There is plenty more information about it Elixir’s README, including some other cool features like real private methods (maybe it will also be included in Ruby 2.0?) and local method calls.

You can always learn a lot by using other Object Models and this tip is not restricted only to Elixir. For instance, if you are not familiar with Javascript’s Object Model or other prototype based languages, I recommend you to learn it now!

Just learn

As I mentioned in the screencast and in the README, contributing to Elixir is quite easy because both the Standard Library and tests are written in Elixir itself. Now, imagine that you had to implement something like Ruby’s Set in Elixir. You would not learn about Ruby’s Set more, but also think about the best structure to use, which algorithm would be the best to update the Set and what would be a good API to access those objects.

Besides, there are other basic tools that are required in any language, like packaging system, documentation parser and test libraries that are currently missing in Elixir and you could be the one to implement it!

Wrapping up

I hope I have convinced you to try out Elixir. You can learn much more about the language itself by checking out its README.

Finally, if you need some inspiration to do crazy things, I recommend the Forking Ruby talk by Dave Thomas. As he said, we love Ruby and we are not moving away from it anytime soon, but forking it or trying out new things is a great way to improve the language and its ecosystem, and I hope Elixir helps you think more about that.

Tags: elixir, erlang, ruby
Posted in English | 14 Comments »

NOTE: Elixir has changed since this screencast was made and the code built on the screencast no longer works.

In the last couple of months I have spent some time learning and improving my skills in other languages besides Ruby. This time, I had the opportunity to know Erlang much better and I was impressed by the Erlang VM and the Abstract Syntax Form it provides. As a result of my first experiments with such tools, a new language was born: Elixir.

The main focus in Elixir is to provide a charming syntax and method dispatching on top of Erlang. Most of Elixir’s syntax and a few features like method_missing and module_eval comes from Ruby, allowing you to achieve similar features when it comes to metaprogramming. However, Elixir is definitely closer to Erlang than anything else. Single assignment variables, immutability, easy communication between processes, lists, tuples, binaries and OTP behaviors are all available in Elixir.

This weekend I made a screencast that builds a simple chat client/server with Elixir. In the screencast, you will be able to learn more about Elixir’s syntax and see how easy it is to make communication between processes:

Building a simple chat client/server with Elixir from PlataformaTec on Vimeo.

The code produced in the screencast is also available in Elixir’s repository on Github.

One thing to keep mind though is that the screencast is only for learning purposes. In real life, you would build such servers using one of the several behaviors provided in Erlang OTP. Currently, Elixir supports only gen_server, but adding new behaviors is quite easy and will be done on demand. If the overall reaction is positive, I plan to do another screencast later doing the same example using OTP behaviors.

PS: Sorry about the strong key strokes in the video, but I was using Macbook’s internal microphone to do the audio recording. If doing screencasts becomes frequent, I should probably buy an external microphone or learn how to treat my keyboard better.

Tags: elixir, erlang, ruby
Posted in English | 6 Comments »