Hi, I am Saša Jurić, a software developer with 10+ years of professional experience in programming of web and desktop applications using Erlang, Ruby, C# and C++. In this blog you can read about Erlang and other programming related topics. You can subscribe to the feed, follow me on Twitter or fork me on GitHub.

Interview with Yurii Rashkovskii

| Comment on this post

Thanks to nice people at Erlang Solutions, I have had the pleasure of interviewing Yurii Rashkovskii, one of Elixir language key contributors and author of many important libraries in the language ecosystem. Later this year, Yurii will be giving a talk on Elixir at the Erlang User Conference in Stockholm and in this interview he shares his thoughts on the language and related topics.


Hi Yurii, nice to have you here! Could you please introduce yourself to the audience?

Hi Saša, thanks for having me. I am a software craftsmanship enthusiast with over 15 years of professional experience and a core contributor to Elixir. Over the years I've been working on various open source Erlang projects, including erlzmq2, beam.js, socket.io-erlang, EEP 39 and others; I've also contributed a couple of projects to the Elixir ecosphere (expm, relex, somlos, genx and others). 


In your upcoming EUC talk, you will present Elixir, an alternative BEAM language. Why do we need another language for the Erlang VM? What shortcomings of Erlang does it address? 

It's a good question. I would start answering it by saying that projects like Elixir allow to broaden the area for experimentation around Erlang while keeping all the good parts of it. As any 20+ years old project, Erlang has some crust, that's inevitable and expectable — and in a way, even good. Mainly, Elixir addresses the lack of meta-programming techniques available in Erlang. Yes, you can do some really hacky stuff with parse_transforms, but they are hard, backwards and fairly limited. It also tries to address less (but nevertheless) important aspects such as standard library consistency, support for Unicode strings, etc. 


In your opinion, which Elixir's key features stand out and make developer's life easier?

Metaprogramming and the ability to generate code is by far the most important feature. I also find Elixir's standard library to be a huge productivity booster. 


How does Elixir compare to Erlang? Is there any performance overhead? Can they interop?

Elixir is Erlang, there's no overhead for calling functions either way, and that's the beauty of it. It compiles to Erlang and makes Erlang compiler do all the optimization; all data types are the same. Elixir also provides some helper modules to make writing some of the OTP behaviours less tedious. 


I know this sometimes confuses people, so could you clarify: is Elixir object oriented or a functional language?

It is as object oriented as Erlang is, same goes for being functional. Elixir has no substantial deviations from the core Erlang philosophy. 


In your opinion, how hard is it to learn Elixir, once a developer is familiar with Erlang? On a related note, should a developer learn Erlang first, or can she immediately start with Elixir?

If you know Erlang, it is not hard to learn Elixir at all. It'll mostly be a different syntax to what you already know. Now, to learn its metaprogramming techniques, it might be harder. If you know Lisp, you'll most likely get it going very fast. Otherwise, expect to spend a week or two having "difficult to understand" moments. Now, if you don't know Erlang, I think it is best to start with Elixir, while reading an Erlang book like Learn You Some Erlang (Hi, Fred!) in background. The reason for making Elixir primary in this education process is that Elixir is essentially a superset of Erlang (whatever Erlang has, Elixir has it, but not the other way around); if you only studied Erlang, then you would have to go "upwards". 


Do you use Elixir in production, and what are your experiences?

Although Elixir is still pretty young, I don't have much of a problem running it in production — largely because of the trust one can have with BEAM — running Elixir in production is as solid as BEAM is. Of course, the question is what code does Elixir generate — and we have had numerous edge cases where the code produced was not doing what it was supposed to do... But if you write at least half-decent tests, you can catch this. Hopefully all of those edge cases have been eliminated... but of course, you never know :) My experience is so far very positive. I've recently developed a few tools helping me with releases (somlos and relex) and creating production releases has become a much easier task. 


Do you receive feedback from other Erlang developers about Elixir? What do they think about it?

Good question. It seems to be a split between "I hate it, kill it now", "I don't care" and "This is so interesting!" — with a tendency to slide to the right when exposed to the language deeper. There are still zealots out there, of course. To them, whatever is not "pure Erlang" is never going to be right. I suspect it to be a certain case of Stockholm syndrome (pun intended!) — because IMHO, the more languages are available to Erlang developers, the better. Time will show who's right, though. 


Currently, Elixir is at version 0.8.2. What is left to do before releasing 1.0?

From what I understand, main goals for 1.0 are: improved meta-programming primitives, release management, better log printing, some code improvements. 


In addition to being one of key Elixir contributors, you have developed many 3rd party tools and libraries for its ecosystem, such as relex, genx and most recently exdoctest. Could you give us a highlight of the ones you find most useful?

By the way, exdoctest is a part of Elixir standard library now (ex_unit). I personally think my most useful contributions to the Elixir ecosystem are expm and what I committed to Elixir (typespecs, doctests, IO.ANSI, Unicode graphemes, IEx helpers, records improvements, numerous other improvements and bugfixes). 


expm is a descendant of agner. Would you briefly explain what does it offer?

expm is my second attempt to solve the problem of indexing libraries in Erlang, after agner. My main objectives were: 
  1. Make expm simpler and more "modular". If you look into the design of repositories in expm, you'll see how flexible and modular it is. 
  2. Make publishing easier (it was a notoriously inconvenient process in agner) 
  3. Have a simple and pretty web UI to browse. 
It's not perfect yet, but it has been up & running since around October 2012 or so and hasn't been too much trouble.


Recently, at San Francisco Erlang Factory, you have presented Genomu, a concurrency oriented key-value database, you are developing using Elixir. Could you please tell us a bit about it? What makes it different from already available k-v and nosql databases?

It is an event-sourcing database. What this means is that instead of updating data in place, the system appends the log of events with an operation you applied to the "previous" value. The original motivation for it comes from the need to be able to work with the data during a netsplit and have valid, consistent and up-to-date data after the cluster repairs. 


Before parting, would you please announce your EUC talk, who does it target and what can people expect to learn?

It will be a short course into "whats" and "whys" — what does Elixir bring to the table, why does it do certain things one way or another. Both Erlang newbies and veterans will be able to learn some key differentiators and get an idea whether they should try it in their projects or not :) 


So that's it folks. If you have the chance, don't miss this year's EUC in Stockholm. It features an impressive speakers lineup and very interesting talks. If you're there be sure to attend Yurii's introduction to Elixir. As an added bonus, you can meet the author of this blog in person and chat about Erlang, Elixir and unrelated topics :-)

Once again, big thanks to Yurii for this interview, and to Erlang Solutions for making it possible!

Post a Comment