The Rogues discuss Elixir with José Valim. 

Special Guest: José Valim.

 

I’m so tired I could use a wake-up Elixir.

Hey everybody, and welcome to Episode 114 of the Ruby Rogues podcast. This week on our panel, we have James Edward Gray.

Good morning, everyone.

Josh Susser.

Witty greeting.

Avdi Grimm.

Hello.

David Brady.

Currently not seeking asylum in Russia. This is David Brady.

Katrina Owen.

Hello.

And I'm Charles Max Wood from DevChat.TV. This week, we have a special guest and that’s José Valim.

JOSÉ: Hello.

We haven’t had you on the show for a while, José.

JOSÉ: Yes, what was the last time? A year ago, two years ago?

Yes, it was a while ago.

It was about a year or so ago, we read your book.

We heard you hate Ruby now.

JOSÉ: That’s not true.

That’s why we didn’t bring him back, he switched sides. He’s a traitor.

Yeah. He went to one of those functional languages or something.

JOSÉ: Yeah, but I still love Ruby. I still spend half of my week working with Ruby. So, I'm still doing a lot of stuff in Ruby.

Do you guys remember those old TV commercials for the Peanut Butter Cups? “You got your chocolate in my peanut butter!” [Laughter]

“You got your peanut butter in my chocolate!” Is Elixir getting peanut butter in chocolate or getting chocolate in peanut butter?

JOSÉ: I don’t think I'm able to answer this question. [Laughter]

The next line of the commercial is, “Hey, two great tastes that go great together!” [Laughter]

Is functional programming more like peanut butter or chocolate? Okay, this has gone in the wrong direction. Tell us about Elixir. [Laughter]

Oh, geez. I love doing this show.

Why did I get up for this?

JOSÉ: Well, it’s hard. I did not come prepared apparently. Elixir is a functional programming language. But saying that something is functional doesn’t really help, I think. The reason for Elixir being mainly a functional programming language is because you want concurrency, right? It’s not for design functional. Being functional is not the goal.

Being functional is a side effect, right?

JOSÉ: Yes, exactly.

Ouch!

Well, it’s a massive that really can take… [Laughter]

Massively concurrent, right?

Dude, that was the best programming pun ever.

JOSÉ: Yes.

Oh, my God! I didn’t even realize I just said it! [Laughter]

Wow! I’m just going to drop the mic. Call me back at the picks.

Okay. So, you must have been working with Erlang a lot to lead into this. I’m really curious, like what kind of stuff you were doing with it. Are you interested in doing this kind of highly concurrent programming?

JOSÉ: I’ve been using Erlang just internally. There were not, so far, opportunities for me to use it like for clients, for example, at Plataformatec. But the reason I came to this, it’s actually funny --well, not that funny but because I got RSI. I got that in my wrists and I could not work for a while. Then I said, “Well, apparently I have to read more.” Then it was a period where I was really reading and reading a lot and I was already familiar with [inaudible], I had [inaudible]. I always like to play and study different languages. Then at this time when I was reading this stuff, I got the ‘Seven Languages in Seven Weeks’ book which is a very good book. I think you guys covered it, right?

No, we’ve mentioned it.

It’s on our list of things to do eventually.

JOSÉ: Yes, you should definitely do it. I was reading the book and it’s very, very good. It starts with Ruby, and it goes into Io, and all the languages. Then it goes into Prolog, Erlang, and then you have Scala, Clojure, and Haskell. There’s a lot of focus overall on concurrency in the book. It starts with Ruby to tell a little bit about Triads but when it goes into Io, it already starts to talk a little bit about the actual model. And then, you're going through a little Erlang. Clojure has software transactional memory and then there's the Haskell stuff where they do crazy stuff there. Then I read this book and I said the thing I liked the most was not any of the languages in particular, it was the language of the virtual machine and how everything worked, and that was when I fell in love. I was like, "This thing is great. I want to use this virtual machine. I want to use those things they are describing here, those concurrency mechanisms to build the software I have tried everyday. And that's when I started to go deeper into virtual machine and study it more, and the way I started writing more link code. The way I like to describe it is that I loved everything I saw but I hated the things I didn't see. There were things now in the language, in the virtual machine, in the Erlang language that I really miss like having a good construct for doing polymorphism, the ability to meta-program. And that’s how Elixir came to life. And yeah, that's it. I know there are people doing really methodical client stuff in Erlang but I'm not one of them. Even after some time, when I

get to, let's say I'm able to view our client's work with Elixir, I'm very web-focused at it too, right? It will be just a way to deploy in a very powerful web server. And if it has like 50 [inaudible], it’s just going to us the 50 [inaudible], it's no sweat and the performance is going to be great.

One of the things that anytime I read or hear anything about Elixir, I'm always struck by how optimized it is for happiness. It seems like all of the things that it allows you to do is just making the developer happier. Is that on purpose?

Say ‘yes’. [Laughter]

JOSÉ: It's not a direct goal I have in mind because happiness is kind of, I can measure my happiness but it's kind of hard to see how that’s going to affect other people's happiness. If people have this impression in general, I'm really, really glad. And the goals we have, and maybe that's why it affects the happiness is we officially say the goals of the language when I give a talk. I talk about productivity,I talk about extensibility and I talk about compatibility, which is compatibility with the Erlang Virtual machine. So, those are the goals. With productivity and that’s probably what make people happy because we want to give you two so you can write your code there and be predictive on your code. We want to not only give like language mechanisms like macros, we also want to give you good tools, right? Extensibility is to be able to, if that thing does not have your use case in mind, I want to extend it, I want it to support my use cases. I think that if we can make people feel productive and they are not fighting against the language and they are not fighting against their own time like in a standard library, I think happiness is going to be a consequence of it.

Okay. I've got another softball for you. Where did you get the name Elixir from? We all know that naming is like one of the hardest things to do. So, how did you come up with a great name like that?

JOSÉ: I don't know. It was a moment of blessing I guess because Yehuda, he likes to make fun of me. He says that usually the names that I come up with are horrible. He said that if I had invented Rails, I would have called it RubyMVC. [Laughter]

JOSÉ: I don’t know. I really can't remember where it came up. I just say that, “Oh, yeah. Elixir, this seems to be a good name.”

You did not get it from WORDOID.com?

That's where I get all of my names from.

Yeah.

JOSÉ: Really? Please send me the link. I need this. [Laughter]

You need to not use this link.

It's great, actually. I love that site.

Yeah, we just spent José’s next whole day.

José, I've got a question for you. You've said both in talking here and I was watching a video of you explaining Erlang this morning which was good. You said, "The Erlang Virtual Machine is our greatest asset," and that you really designed Elixir to use that asset optimally. Maybe you could just tell us what is it the things about the Erlang Virtual Machine that you just really want? What makes you think that's so valuable?

JOSÉ: That's a good question. Let me think. When I give a talk about Elixir and as I said,most of what I do with Elixir is thinking about, “In the future, I'm going to use it for a web application,” right? I wantto develop end points. I want to be able to build APIs with it or build systems that are highly connected. There are many things. I will start the story from scratch. The Erlang Virtual Machine, it was created by Ericsson. At that time, it was the 80's when they started the virtual machine, they are not really thinking about running many parts because it was not a problem back then, right? But the use case they had, for example, to build telephone switches. So, a telephone switch is a machine somewhere that’s receiving a bunch of connections and it's juggling all these connections at the same time. From here, you've already got one thing. You need to be able to do a lot of -- you need a switch to be able to handle as many connections at the same time. So, it needs to have this ability of handling stuff concurrently. They also wanted robustness because if you need to install a switch in the middle of the forest, you don't want to go there every two weeks to give maintenance to it. When you have a call, you need a different switch to talk to each other because you need to route to different switches or maybe the person is already busy talking,the connection is already in another switch. So, they also have these distributed aspects. They have different nodes, they need to be able to talk to each other, different information. So they got all these things together and they made it the virtual machine. The reason why I think Erlang came up is because it's from the end of the 80's and in I think 2004/2005, people started to use it a little more. And I think because people realized this thing that I'm describing,this telephone switch is actually what is happening on the web, right? You have a server there. It’s receiving a bunch of connections at the same time. It needs to handle all those connections. There are requests, there are responses. You need to talk to an internal API. So, it has really a bunch of features. Then I said, "Wait,I feel that if I build software here, I will be able to build great software. I'll be able to build robust software. I'll be able to build distributed software. I'll be able to build concurrent software.” Those are all the things I saw in there and that's where I'm going in the direction of.

You mentioned there ‘routing’ just there, that you’re kind of thinking about routing, say for web applications and that was actually a prominent example in the video I watched this morning. It was kind of interesting. Can you talk about why you think that relates to the Erlang Virtual Machine?

JOSÉ: That's more kind of an indirect thing. That's more of using the features of the language and the features provided by the Erlang Virtual Machine. One of the things in Elixir is that-- and most of the time, when I say Elixir, you can also think of Erlang Virtual Machine. The main thing is that you do pattern matching. A function can have many clauses and then you can put guard, you can put specification on those clauses. What you can do is that you can check if a string starts with hello at the function clause. Then if it starts with hello, you can do something. And then if the string does not start with hello, you can have a fall back clause. You are going to do something different. You can really do a lot of code like stuff. You can match a list, you can match a tuple, extract elements. So, it's a really powerful construct. This is handled by the Erlang Virtual Machine. So, the virtual machine gets all of those patterns and they need to compile to the fastest way possible, they want to be optimized. They have been optimizing those patterns for 20 years already and it's like super, super fast. The thing about the routing like the routing in Rails is that it's exactly the same stuff you are giving it a bunch of patterns which are URLs and you want to dispatch to an end point. You want to do some specific action where the URLs match. What people do when they are implementing routers is that they go with the most naive solution possible which is if I have a round of routes and I'm going to check those routes one by one until I find one that matches. What it can do, and that’s the simile to a pattern matching. Aaron Patterson, we can search the link later. What Aaron did, for example, in Rails is that he changed the Rails router, I think for Rails 3.2. And he used it as actually the pattern matching theory to compile the routes into a graph. So, you don't need to match one by one to find one that matches. You go in the graph and then if you have a starting node, you already know where you can go and where you can't go. You can very quickly say if there is a match or not. If routes, for example, they have the same prefix, you don't need to match on those seven or eight different prefixes and all the same patterns. You just create a graph of the actions that you can go and cannot go. What we did for Elixir is that since we have pattern match on the language, and we have this meta-programming ability, what we do is that we get our routes file and we compile this thing into those pattern matching that are highly optimized by the virtual machine and that makes it super, super, super fast. The implementation is 150 lines of code or 100 lines of code of a decent router that’s going to be one of the fastest routers you can think of writing. It’s really nice. It’s just the coincidence of having a feature in the language, having selfconducting virtual machine really knows how to optimize, and putting those things together.

That’s cool.

I like that because it’s the way that -- it corresponds to how I like to do stuff in object-oriented languages where you want to get rid of conditionals and case statements and things like that and just use polymorphism and the virtual machine’s super optimized method dispatch mechanisms. You’re doing the same kind of thing by getting rid of those conditionals and case statements by using something highly optimized that’s built into the virtual machine. It’s great when you do that because it’s like you’re going with the grain and the language just helps you do that. Did that make sense?

JOSÉ: Yes, that makes total sense.

So far, we’ve talked about mostly things that Elixir kind of shares in common with its Erlang base. I have a lot of questions, I’m a big language nerd. I have a lot of questions about your choices for Elixir specifically. First of all, it seems like a lot of the syntax is Ruby-inspired. There are obviously a few other inspirations in there, a little tiny bit of Python and stuff like that.

It’s docstrings.

What’s that?

Docstrings! He took the best part of Python. [Laughter]

I was actually thinking about triple equals but yeah. Having done some functional programming, it felt kind of weird doing functional programming with a Ruby Style Syntax. I’m curious, is the Ruby Style Syntax basically just there for approachability for people coming from Ruby or Ruby-like languages? Or do you actually feel like that kind of syntax is a good fit for functional programming? It felt kind of strange to me.

JOSÉ: Syntax is kind of hard to discuss. Obviously, since I’ve been doing it for five years of my life, I was doing a lot of Ruby. So, it naturally comes out of a lot of inspiration from there. One of the things that I think gives it a lot of Ruby feel, is that I have additional parenthesis. I think this is one of the single things that give it a lot of this Ruby feeling and probably the do/end blocks.

Right. Although there aren’t a lot of mandatory parentheses in Haskell, so that’s Haskell-ish as well.

JOSÉ: Yeah, that’s true. I have a couple design rules coming up with the language and the current syntax. Yehuda also helped me in the very first versions which is basically what I wanted to have is that I knew that I wanted to have macros. The way I wanted to approach macros in Elixir, basically I wanted to have meta-programming, let me fix that. I wanted to have meta-programming. One of the ways to have meta-programming is macros so that’s what I’m going to look at. Then, you see the things that allow you to do macros and macros for them to be any kind of way same, you need to have a regular syntax. Having a regular syntax, if you go to the extreme opposite, you have Lisp, right? It’s extremely a regular syntax, Clojure gets a little bit away by a lot of [inaudible], add brackets, curly, and some special stuff, but is extremely a regular syntax.

That’s what makes meta-programming in Lisp so sane is that you can just look at it and see the AST. And so, it’s very easy to understand the transformations that you make when you’re metaprogramming.

JOSÉ: Exactly. So, I say Lisp is like what you see is what you get, right? What you're looking at is what you’re getting. I wanted something mid-term, I didn’t want Lisp. We already have two other Lisp implementations in our virtual machine. I’m not particularly a Lisp fan. I find it very elegant but

I don’t find it beautiful if it makes sense. So, I said, “Okay, I want to have something else. And then, I needed to have a regular syntax.” That’s why when you go to Elixir, everything has do/end blocks.

So, when you define a module, you need to put do/end because module is not a keyword. Defining a module is not a keyword. It’s like anything else in the language. Everything translates to a very common AST so the way we present operators in that state, even before we have the sign operator notation, it comes with everything else in the language. Our AST, for example [inaudible], the steps that you need to do mentally to go from one step to the other is very few. There are very few translations that you need to do. And that’s one of the first rules of the language. Even so, when we got that, it was still very, very robust and then it was adding constructs little by little that was getting those common cases and making them easier to write. For example, the do/end, it’s kind of hard to say with words without showing the code. But the do/end in Elixir is the equivalent of putting parenthesis, of wrapping our stuff with parenthesis. It’s a convenience of say, a block of code because in particular, if you have parenthesis there, it would get very weird and clunky easily. So, we say, “Okay, let’s abstract this pattern.” Then we got a lot of stuff out of it and when we were abstracting, it often came, “Well, I am getting this. I want some of this pattern. Let’s look at [inaudible]. Ruby has do/end blocks. Let’s use do/end blocks then.” That’s one of the things we approached it. I tried to keep the data structure syntax all from Erlang. I tried to also keep a lot from what we have in Erlang. So, tuples, they look the same in Erlang. Lists they look the same as in Erlang. Binaries they are extremely similar, they’re not exactly the same but they are very similar. So, there was also lots to do in Erlang for those data structures, those operators unless they don’t make sense because we have a couple of those in Erlang where they are not making any sense. For example, the less than equal operator in Erlang, is the equal sign first and then the less than sign, it’s the opposite. So, we said, “Okay, we’re not having this.” Then we make the notation where we have [inaudible]. I’m obviously biased but because we have better matching in tuples. So, if you go to case expressions, if you get a case in Elixir with pattern matching or a receive, it feels functional to me. The only thing that doesn’t feel very functional to me and that’s probably where some of your feeling is coming are the named function definitions, even more because if we show a program line, it’s very common for it to have a bunch of inline definitions one close to another. They don’t look as great in Elixir, in my opinion. It’s not as good as I would get in Haskell, or CAML, or even in Erlang, like a one function line definition in Erlang for me is prettier than the one in Elixir.

So, that may give a hint.

I think you may have actually nailed something I hadn’t completely identified in looking at some of the code that I wrote is yeah, when you have a bunch of function definitions of the same function for different arguments next to each other, it’s not quite as pretty as you’d see in like a Haskell.

JOSÉ: Yeah, we have a little bit of that but those are things that we discussed. We could insert a tradeoff but it would be a special case and then we decided that we cannot make everything look good all the time. It’s just a tradeoff that we need to have.

I was also kind of surprised that the Lambdas, the anonymous functions look so different from the named functions, like the syntax seemed so different.

JOSÉ: Yes. This comes up a lot and that’s because they are actually very different. There’s a lot of people who say, “They look different things.” And that’s because the Erlang Virtual Machine treats them as very different.

Interesting.

JOSÉ: Not necessarily internally, I’m not sure about the internals that much, how they are treating it. But on how you are calling them in the code. One of the things, for example, I’m not going to have an example on this. I had an example in my mind but it just escaped me. We can go back to this.

That’s alright. I have another question about just the overall language design. A lot of the stuff that I’ve messed with so far is just kind of a different syntax over a functional core over the Erlang. A lot of it is very, very familiar semantically. A lot of it is very familiar from other functional programming languages, the pattern matching, the recursion, defining a few different versions of a function and stuff like that, passing functions around a lot. Do you have any currently or in future, are there any big ideas semantically that you want to add to it that you wouldn’t typically see in a functional programming language? Or is it basically going to be the kind of semantics that you usually see. It’s not a very well-put question, I’m sorry.

JOSÉ: That’s a good question and the Erlang Virtual Machine doesn’t allow you to do much as a language. You can try to do different stuff but it’s really going to be suboptimal. And so, the first Elixir version was horrible. When I started writing it, I was really -- first, I didn’t know very much what I was doing. I knew that I wanted to have some things so I knew -- if we go back to the goals, I knew I wanted to have a way of achieving polymorphism but I didn’t know how I wanted to do that. For example, I would say, “Let’s try to have the polymorphism the way I know about which is by having objects.” And then, I'm going to call things in those objects and then I get polymorphism out of it. Then I was really trying to push goals in other semantic directions. That's what made it not good because first, having immutable object is a disaster, right? If you have objects and you can't mutate them, it becomes really, really tricky.

Well, I think of Erlang/Elixir objects as being the processes, right?

JOSÉ: Yeah. So, this is one of the ways that we look at it. I was really trying to add objects, right? The data, the structuring object and then I could add stuff in it. And then, low semantics, performance was specifically horrible. It felt weird to use because you start to go into things, you can’t actually -- if everything is immutable when you have -- that's why having immutable objects is so hard because you have objects that depend on each other. You have a tree, right? So when you need to update something, if you need to update something nested in the tree, you need to go all the way up in the tree, propagating your changes. If you have a nested object dependency and you want to change a leaf in this tree, it’s very complicated because you need to propagate he changes all the way up. That’s what felt hard and then, there were a lot of this stuff that I was going to the problems and then I was saying, “Well, I know the solution and that solution was obviously not working.” That was when I decided, “Let me stop whatever I’m doing here.” And if you go to the commit graph, you can see a period of inactivity. And that’s when I really decided to study other languages and how people were solving those problems that I wanted to solve but in functional programming languages. I wanted to have polymorphism. And I said, “Well apparently, Haskell, they’re using this class type thing.” Go has come up with this idea of interfaces, and Clojure has protocols. Then I say, “Well, this protocol thing looks great. The other languages, they are statically typed. Elixir is dynamically typed. Clojure feels closer to Elixir. So, I know I won’t implement protocols in Elixir now.” Then when you really want to manage a state, we have solution for this in the Haskell community, for example. They have this thing called lenses and transversals that allows you to update deeply nested structures. What I’m getting at is that if you’re adding more semantics, you’re probably coming from the functional side than from anywhere else.

In other words, you might add some functional features that aren’t present in base Erlang, but probably not so much stuff from procedural or OO languages?

JOSÉ: Yeah. We already do that. One of the things -- if we start going through the differences between Elixir and Erlang, one of the things I already talked about metaprogramming is having protocol which is a way to achieve polymorphism. And we have, in general, a very complete standard library. Now, I’m going to do a little bit of criticism of Erlang. In Erlang for example, you have a list type, you have an array type, you have a dictionary type and if you want to iterate a dictionary, if you want to iterate a list, if you want to iterate an array, if you want to iterate a set, they all have specific functions.

Right, that was exactly the kind of insanity that Rich Hickey was coming out against when he did the protocols in Clojure, right?

JOSÉ: Yeah, exactly. It’s very hard and often, they use different names. There’s the fact that you need to know different APIs and there is all the semantic loading of having to know those different names and what they mean in those specific contexts. Then we have the enumerable protocol which is, you can give anything that you teach the language how to reduce, you’re going to be able to use those functions. Then we can keep the set of words the developer needs to know and work everyday, we keep them very small and that’s extremely important.

I guess that’s one of the bonuses of writing a new language is you get to start all over with a standard library and make it the same, make it consistent, I guess, is the big thing. Speaking of your standard library and the Erlang libraries which are a little different, there’s always a fear when somebody’s getting into a new language that’s built on another language, that at some point, they’re going to start using it more and more, they might start using it in production. And then at some point, they’re going to run into a really thorny issue that requires them to know the base language to resolve it. I guess languages like Ruby, they handle that by being implemented in a language that at least, most people know a little bit of, like C. Is that something that, at this point, people are going to face with Elixir or do you feel like you can get quite a lot done without having to know any Erlang?

JOSÉ: I feel you can get quite a lot done because -- I was talking like, you cannot really change the semantics, I was talking. If you are in Elixir, you can stay in Elixir land and then if you need to step a little bit into Erlang, it’s not going to look that foreign anymore. Of course, the syntax is different but at that point, you’ve already absorbed most of the semantics. Even so, let’s suppose you want to use Elixir today, you want to replace your Ruby use for scripting and you want to use Elixir. You’re going to use Elixir and you’ll be fine and you probably won’t have to worry about Erlang and you won’t have occasions to worry about Erlang today. So, the situation flow that you meet today is that if you want to build -- Erlang shifts with this thing called OTP which is kind of the Erlang standard library. OTP has all the patterns that you need to build those distributed systems, those concrete systems we were talking about. And if you want to use those today, you need to call Erlang functions. This is a message that I’m sending since the beginning of Elixir, the Erlang Virtual Machine is our strongest asset and the Erlang OTP, the way they have been building those systems, it’s our asset too. Sometimes people say, “Wait, I think we should wrap this library.” And I would say, “No, we are not wrapping in libraries. You need to be able to learn how to use them.” But it’s just a matter of you opening an Erlang documentation page and then reading all the arguments and passing the arguments to it. But the names, here’s expecting a list, what they’re calling a list there is going to be a list in Elixir. The semantics, the types, they are all the same, so it doesn’t feel like a huge hit. There is one thing which is a blocker for this error getting into 1.0, and it’s one of the Elixir second articles which is to improve the error messages. The error messages in Erlang, they are very bad, very, very bad. So, it’s one of the goals to have. If something fails, we want to give you a nice message of what failed and how it failed, and what you should do from there. Every time you work with Elixir, you call something and you get a weird message, you can open up a bug. And if we can improve it, we’re definitely going to improve it.

Can I ask a question about that?

JOSÉ: Sure.

Is this something that you can do only for the Elixir standard library or can you also improve the error messages on top of Erlang when you’re delegating to the Erlang standard library?

JOSÉ: We can improve many things on that side. It’s funny because there’s Basho, the company that runs Riak. On top of the Erlang Virtual Machine, they created Riak and they have our similar goals. I was talking to them and some of their goals are very similar like they want also to improve the error messages because sometimes people are starting the Riak node and then when they are starting it, they get bad match. [Laughter]

That’s one of my notes is that when -- I like that it’s a neat pattern when you say the tuple of ok and a value, matches against io.open or whatever the call is to open a file. And so, that’s only going to match when it returns a tuple that includes ok rather than error as its first element. That’s kind of a cool pattern. But then, the error that you get out of it is (MatchError) no match of right side of value {:error, :enont} which is a terrible way to say, “File not found.”

JOSÉ: Yes, exactly. There’s actually a story about this. I was talking to a friend he was telling me that the first time he went to use Riak, he installed, did a lot of things, and then he tried to run the node and then he got exactly a bad match. He tried to run bad match, bad match, the error was exactly this message {:error, :enont}. And then he said, “Let me try to fix this.” Then he added a stack trace and until like two or three years ago, Erlang did not have line numbers in stack traces but he was trying to start Riak and was getting {:error, :enont} and then we have no lines of stack trace. He was able to find the module, the function. And then, he figured out what was happening was that they were trying to open to create a log file but they didn’t have permission to write to that directory. What he was getting out of it was a bad match. The way we were trying to improve this, these in particular we cannot improve it. It’s a bad match that’s coming from inside the Erlang Virtual Machine and we can format it nicely, but we can’t change what is happening. It is how the software is written. The way we tackle this particular issue in Elixir is that in Elixir, the Bang method, the Bang functions, they are for exceptions. Just so you know that function can raise an exception specifically and we followed those.

Just a quick question. Is that syntax? Can I turn anything into a Bang method or only when it’s specifically provided by the library?

JOSÉ: You need to specifically provide it. We cannot do it automatically because it depends on which exception you want to raise, what is the information you want to put in the exception, but we keep the following design goes that exceptions must not be used for flow control. That’s the nice thing about the ok pattern. The ok pattern is excellent for flow control. If you get ok that thing, you are going to use pattern matching to decide how to do it next and this is excellent, this is beautiful but there are many cases. Like I’m trying to create a log file that my only exception is to create a log file. If I can’t create that log file, my software should fail. There is nothing I am supposed to do and that’s when you’re going to raise an exception and the exception is going to -- they have messages in them. And the messages are going to tell you exactly what you have to do. So in Elixir, if you try to file.read/bang and the path, you’re going to get a nice message telling you exactly what happened. We try to have the best of both worlds. We try to have better matching for the cases you care. And the cases you don’t care, you just call them out with bang and we’re going to do our best job to show something nice to the user. Since we have both, we can say, “Do not throw an exception. Do not use exceptions for control flow. Use the pattern matching approach.” And that’s like best practice. We are telling people what they should do.

I was just going to say the match error, it feels like that has a potential to be Elixir’s no method error on nil from Ruby.

Which always gives you so much information. [Laughter]

Yeah.

I kind of wanted to ask, we’ve talked a lot about several features of the language and some of the ways that it can be used. But I’m wondering if you see this going more in the direction that Ruby’s gone where a large portion of the use for the language has gone to web? You’ve mentioned that your background is mostly web anyway. Or are you hoping to see it kind of move into some of the spaces that Erlang is in like Riak and building some of these concurrent backend systems?

JOSÉ: My hope is that it’s both. I want to have both running there and there are people that are building databases on top of Riak and using Elixir as a language. So, I really hope for us to get the best of both worlds. My main experience is with the web part. So, I will personally build projects related with this area. Right now, we have a project that’s about querying the database. So, we want an easy way to query the database and talk to the database and that’s because I need a database, I need to use a post query, I need to use for building our application. But all the things that people use to build the systems in Erlang, they are there. Erlang ships with a database called AMNESIA and it’s distributed. So, you can use this if you want. You can use Riak and there are people who are using exactly the second category that we’re talking about. People are using Elixir, they need to work at a TCP level for example and handle many connections at the same time. They are juggling information from one place to the other. I hope it’s going to be great for both use cases and possibly more.

I have a completely new question. You said at one point elsewhere that everything in Elixir is an expression. In Ruby, we tend to talk about how everything is an object and that has really interesting implications. I was wondering about what the implications of ‘everything is an expression’ are?

JOSÉ: Okay. I think in Ruby, everything’s an expression also. We don’t have statements.

Can you clarify the difference?

JOSÉ: I will clarify. Yeah, just help me, James.

Go ahead. Go ahead.

JOSÉ: About Ruby, so using Ruby.

In Ruby, there are a few kind of weird edge cases. Just to give one off the top of my head, you can do assert(!not), you could do bang and then something, like not something. But in Ruby, you can not do assert (not) and then something, if I remember correctly. There are just a couple of really weird edge cases like that. But for the most part, what you’re saying is true.

I think there’s a couple odd little things in Ruby where you technically get a return value but it’s nil.

Like when you do a def of a method or create a class.

Or a class, yes.

Oh, yeah! Talk about how that is in Elixir. That’s awesome.

Does def return something?

JOSÉ: Def returns the name because functions in Elixir, you don’t recognize a function just by its name. It’s by the name and the arity. This means that you can define functions with the same name with different arities. We return a tuple where the name is the first argument and the arity is the second one. It would be really cool in Ruby if it return like a method object and maybe [inaudible] with it.

That would be cool.

[Chuckles] Yeah.

JOSÉ: [Chuckles] I think Rubinius did that for a while.

I was actually thinking of what you return for modules in Elixir, is really cool.

JOSÉ: What we return for modules, it’s awesome. What we return -- okay, let’s answer first Katrina’s question and then we go back. I think, James, the thing that is sad about assert not is more of a syntax restriction, or not really?

Yeah, I think you’re right.

JOSÉ: Okay. Expressions, they return a value; statements, they do not. That’s a very simple definition we can think of. In Ruby, everything is an expression because you can call method, [inaudible] as argument because that it is going to return a value because everything is an expression, everything returns values. I think JavaScript is not like that, for example, and it’s one of the things that Coffee Script tries to solve. They make everything expressions, everything has return values. When we say for Elixir is that everything is an expression that’s one of the things, that’s what we mean that everything has a return value. But when I’m saying that, I’m doing a construct directly to Erlang because in Erlang, you have two things. You have expressions and you have what they call forms. A module is made of forms. In Erlang, a function definition is a form. We have something called module attributes that they are forms also. But you can’t put any regular code in the middle of the Erlang module body because it just allows those very few things. This makes it very hard for you to execute something while the module is being compiled. If you want to explicitly define a function in Erlang conditionally, you need to use like template preprocessors which is their macro system. It’s a completely different syntax. In Elixir, we just wrap that thing in an “If” and it’s going to work exactly because everything is an expression. And that’s one of the things you get out of it. The other thing that you get out of it is that whole thing about having the AST representation of the language, very familiar and very simple because everything’s an expression. We don’t have those different things to worry about. You can express everything the same way. We were talking about something else and I said we would roll back, what was that?

The return value of modules.

JOSÉ: Yes, thank you. Since everything’s an expression, if you open up the Elixir interactive shell and you define a module, you are going to get back a tuple with four elements. The first element is simply the atoms. When they say atoms, they are Ruby symbols. They are pretty much the same thing. We simply return an atom called module because we use a lot -- it’s very common to tag tuples in Elixir and Erlang so we know what that tuple is about. First one I might say, “Oh, this is a module.” The second element is the module name. I will skip the third. The fourth element, since the module is an expression, at the end, we have to return a value. The last thing you execute in the module body, we return that as the fourth element. And the third element, this is the nicest one, is the module byte code. What I do when I am showing Elixir at conferences, what I do is I load up two Elixir shells in my computer. I have the Raspberry Pi, so I usually load it in the Raspberry Pi. And it’s very easy for you to make those two shells talk to each other because it’s very easy to have these distributed things in Erlang. What I do is I get the byte code from one shell and push it to the other. And now, the module I defined here, pops up in the other shell and I can call stuff in it.

I kind of want to jump in here for a minute because we’ve talked around this a little bit and I’m just not quite clear on it. Does Elixir transpile into Erlang or does it run on the Erlang Virtual Machine with its own syntax tree? Then the other question I have related to that is, can you call into existing Erlang libraries?

JOSÉ: It compiles directly to Erlang byte code and you can call Erlang libraries with no conversion costs whatsoever. If you get two similar modules and you compile them from Elixir and from Erlang, the final byte code is going to be very, very similar.

Does Erlang compile then to byte code as well?

JOSÉ: Yeah. It’s what we call the .beam files, yes.

Okay.

I got a little bit of a different direction to pursue here and that is the Erlang language is an implementation of the Actor Model. I started off calling it a functional language but really, it’s an object-oriented language. All of these actors are like objects but they can all operate concurrently rather than sequentially which is how the Smalltalk variety of object orientation went.

Can I just contribute a quick quote about that?

Yeah.

I found this the other day. Erlang’s Actor Model gives it the distinction of being the only language that claims not to support object-orientation while actually providing full support for it. Languages that claim to support object-orientation but don’t, are far more common. [Laughter]

The history of that model was way back in the 70’s when Alan Kay and the Learning Research Group were inventing Smalltalk. They went and travelled around and they showed off Smalltalk and Carl Hewitt was like, “This is amazing! I’m going to do this actor stuff.” The early Smalltalks felt a lot more like JavaScript, I think, in the way that classes were built, et cetera. So, things aren’t as far apart as these people tend to believe these days. But I’ve never gotten to work in an Actor Model language and I’m curious how it feels in terms of objects and encapsulation and objects all the way down, and everything’s an object. That’s the way we think about things in Ruby. But I’m curious how that feels when you’re working in Elixir. Does it feel like you’re inside an object or an actor versus outside? And how light weight is that mentally when you’re thinking about programming problems?

JOSÉ: Well, I’m searching for a link that goes exactly into a little bit of this discussion about objectorientation in Erlang. I don’t think I’ll find it. I can search it later but it’s basically saying, the “Alan Kay” and the whole message passing stuff and they say, “Well, Erlang is actually the only one that’s [inaudible].” Then he goes and explains why people say that, but he says that the way you need to think, you should not come with the thinking that it’s going to work like the other things. We have those actors in Elixir and you can create a bunch of them, but you don’t want to create really like we create objects in Ruby, for example. You don’t want to go crazy and create a bunch of those. I don’t think it feels similar because the mechanisms they operate is very different. You have an explicit pattern matching. So, when you send a message, the message that is sent is a data structure and then when you are receiving those messages, you are pattern matching those structures and acting on them. You need to do the recursion. So, you are specifically doing the recursion or as your actor, he exits, he gets out of its loop. It doesn’t feel like you are in an objectoriented language if we say that object-oriented language is what you’re doing everyday in Ruby or Python, or whatever. It maps differently. But your mind is thinking differently also because it doesn’t map correctly. So, you’re not thinking about creating those objects all the time. You are thinking about having, you think, “I’m going to create a process.” The first reason why you want to create an actor in Elixir is because you want to encapsulate state because there is no way for it to have state otherwise. The only way for it to have state is to have those actors and sending messages to them for them to return part of the state or to change their state. It doesn’t come, “Well, I need to create this object because I need to model this thing.” It’s not that. It’s because I need this state or I need to have those things running concurrently and talking to each other. I’m going to a risk in saying less about structure and you think more about communication.

I think that’s pretty cool. When I say object-oriented programming, everything’s an object, really it’s all about messages in the Actor Model in Erlang. And it sounds like in Elixir, the focus is still on that, in the communication, as you said.

Almost message passing is required, right? Because of the way the actors work. The Erlang book from the Pragmatic Programmers has a pretty good quote about this trying to think about it in your mind. It’s basically like how humans interact. You can’t just make another human do something else. Instead, you have to explain to them what you want them to do. You have to communicate and pass those messages across and then that human will do their own thing and accomplish it in their own way. It’s kind of like that.

JOSÉ: Yes.

So, are you saying we should treat software like people instead of treating people like software? [Laughter]

It deserves it more.

Hey, we’re always about empathy on this show, right?

Yeah. I empathize with those people who create software that’s not worthy of being treated like a person. Alright, well… [Laughter]

That was your cue to speak up, software!

Does that mean time for picks?

I think so. Is there anything we’ve missed that we totally should have talked about?

Yeah. Let me just say one thing before we run off. If you’re listening to this episode and you want to fool around with Elixir a little bit and learn a little bit of it, I just have to say that the website is actually quite helpful. It’s got some highlights on the front page but there’s a link to the Getting Started guide which is actually quite good. It goes through several chapters, hitting the main points and stuff and kind of eases you into Erlang. So, it’s good stuff. It’s helpful.

Nice. Alright. Well, let’s go ahead and get into the picks then. Avdi, why don’t you start us off this week?

Alright. Well, I will start with something very, very topical. I don’t think we’ve actually mentioned it yet. Forgive me if we have. But as part of my prep for this show, I watched the PeepCode Screencast. Did somebody already mention that? I see it’s in our show notes already. I’m just going to mention it again.

It wasn’t mentioned.

Okay. [Chuckles] I watched the PeepCode Screencast with José and it’s like two hours long going through a simple project in Elixir from like the bare beginnings. And it was very, very informative. I enjoyed it. That, along with the Pragmatic Programmers book, helped me get started quite quickly. So, definitely check that out if you want to get into the language. For a less programy pick, I have got a new Netflix show to recommend. It’s not made by Netflix but it’s available on Netflix. I have to make that distinction now because they’re making shows now. It’s a show called ‘Wilfred’. It stars Elijah Wood and it’s basically Fight Club if Tyler Durden was played by a stoner Australian in a dog costume.

[Laughs] Okay.

I’ve got to call in sick today, so I can go watch it. [Laughter]

What?!

I think that’s enough to pique your interests. So, go check it out.

Alright. Katrina, what are your picks?

I don’t think I can top that.

I have one that’s relevant to what we’ve been talking about today. It’s a movie I saw several years ago and it’s called, ‘Erlang: The Movie’ and it’s not to be missed. It’s about 10 minutes long. Truly hilarious documentary written and done in 1990 for a Telecoms conference and it’s just brilliant. The other pick that I have today is we’re back on sort of Ruby on Rails topic here. Bryan Helmkamp of Code Climate has put together a free Email course about Rails Security. It’s at RailsSecurity.com and I think you should probably take it. I will say no more. JOSH: Can you say one thing more which is what is an Email course?

You sign up and you get Emails with lessons.

Wow!

I’ve never heard of instruction being delivered that way. It sounds almost worth checking it out just for that.

Yes, you sign up. You get the first lesson right away. And then every few days, you get a new lesson. It kind of spaces it out and gives you an opportunity to think about it, to try things out and then get a new Email a little after a few days. It’s really good.

Awesome.

You should probably point out that the Erlang movie is 10 minutes long but you have to watch it in 16 theaters at once. [Laughter]

David, do you want to share your picks then?

I actually have no picks today except that when this episode airs, we are all going to be on airplanes or vans or cars, headed to LoneStar Ruby Conf, is that correct?

Some of us. It usually airs before we record on Wednesday. So, we’ll be prepping to go.

This episode’s going to air right before LoneStar Ruby Conf. And I’ve kind of been on a sabbatical for the past few months since the contract that you and I worked on, Chuck, has finished. And I’m coming out of my sabbatical and I’m just curious. I guess my pick is me. I’m available for full time contract if somebody wants a weirdo on their team. So, hit me up at the conference or Twitter @dbrady. And if you’ve got an interesting project or a really hard problem, or both, I’d love to talk to you. I guess I am my own pick today.

Awesome. James, what are your picks?

I’ve got two. One, I’ve been reading this series of blog articles that Ryan Davis Zenspider has been posting on his blog about his Emacs setup. He has super tweaked over years, I’m assuming, Emacs setup and he’s breaking it all down bit by bit and explaining what all of it does. And it’s very cool if you’re like remotely into Emacs, you can really get a lot out of it. It’s basically convinced me in like three posts. I'm like, “Okay, everything I did in my setup is wrong and now I know how to fix it.” It’s really good. I’ve learned a lot about Emacs and how to manage it and stuff like that. So, check out that series if you’re into that. I’ll link to the first one. Then, I’ve been watching Star Trek: Enterprise lately which is kind of interesting because I think it’s generally not considered to be one of the better Star Treks. I’ve always heard people talk about it kind of derogatorily but I actually am really enjoying it. I’m only through the first season so far, but I think it is probably one of my favorites. So, if you haven’t seen Enterprise, check it out. I know it gets cancelled four seasons in.

So, maybe it goes downhill but the first season, in particular, I thought was really good.

You’ll just love, later in the series, Jeffrey Combs plays an Andorian. And I could just watch Jeffrey Combs all day doing anything. [Laughter]

He managed the Trifecta, right? He’s not old enough to have been on the original series but he’s been on all of the other Star Treks. He was a Ferengi in Next Generation and he had a bit part in Voyager.

He had a big role in Deep Space Nine.

Oh, yeah. He’s huge.

Plus, he was on Babylon 5.

Nice. I finished watching Enterprise about six months ago and I will say that they knew they were getting cancelled before they were done filming. And so, they basically throw a 99 yard pass from the one yard line. Why not? Just total Hail Mary. The episode ideas at the end of the season, it’s like they had nothing to lose. They are a little bit absurd but they are also some of the best episodes of the whole series.

The great thing about that show is now that they’ve rewritten all of history with the new Star Trek movies, the Enterprise TV show is the only TV show that is still Canon.

That’s right. [Laughter]

There’s a tiny quote from Futurama when they had all the Star Trek original series people on. And Scott Bakula does a cameo on that episode. And he’s on there just long enough for George Takei to blow him up and he yells at him, “Thanks for killing the franchise, Bakula!” [Laughter]

Okay. So, that was a great pick.

Check it out. It’s a good show. [Laughter]

I think I still have to do my picks.

Go ahead.

Okay. I can’t top that, though. But I do have a good programming pick. Jonathan Cairns, or @Joonty on GitHub and Twitter, he took my ranting about gem files and the pessimistic version operator really seriously. And he wrote a gem called ‘pessimize’. You just run it and it will take your gem file and insert all of the proper version constraints using the pessimistic version operator. If you put stuff in your gem file and you don’t put a version on it, then you bundle, and then you run pessimize, it will go look in your gemfile.lock and figure out all of the versions that you’re bound to right now and then go and rewrite your gem file with those versions.

I wrote a Ruby script to do that a year ago and it never occurred to me to make a gem file and share it. So, I’m a jerk and @Joonty is awesome.

[Chuckles] Yeah. He definitely beat you to it. Then he wrote a nice blog post on it and why you should care about this and the dangers of bundle update. That’s my programming pick today. Then I have a cute Twitter pick which is @YiddishProverbs. I’m amazed at how much wisdom keeps getting tweeted out by this Twitter account a couple times a day. Growing up in a Jewish family, I heard a lot of this stuff growing up. But it turns out you hear a lot of this stuff just all over the place too. So, it’s just like a lot of the colorful Yiddish words made it into American language. A lot of these little sayings made it into our culture and it’s just kind of cute to see them go by. Definitely, if you grew up in a Jewish family, a lot of this will seem familiar. And even if you didn’t, it’s still kind of cute. It’s right up there with the Picard Management Tips.

[Chuckles] Nice.

Okay. That’s it for me.

Alright. This week has been kind of a crazy week. And so, I’m just going to pick a couple of TV shows. My wife and I just recently started watching Alias. We watched Fringe, so then we started looking for other J.J. Abrams shows. We watched Lost as well. We started watching Alias and we’re enjoying that. Then, there’s a new TV show out that we’ve watched the first two or three episodes of and it’s called Under the Dome. And it’s starting to shape up to be kind of interesting. So, we’ll see how that goes. Those are my picks. José, what are your picks?

JOSÉ: You already took some of mine. The PeepCode is the name for it and Programming Elixir from Pragmatic Programmers. There is also, I think James said about the Getting Started guide. There’s also this blog he has been writing about Elixir and he is writing well. There is another blog I’m going to post the link to about less serious things. I have this Unerdwear. So, I don’t know if you heard of Railsberry. It’s a conference we have here in Krakow. I know Katrina was here. And the organizers of Rails, they made this Unerdwear. And they have actually really nice underwears and the site is just extremely funny. They made it funny and trash on purpose and it has -- well, check it out. Since we were talking about TV shows, I don’t know if you guys watched this one. It was a recommendation I got from Aaron Patterson and it’s ‘Todd and the Book of Pure Evil’. Have any of you guys watched it?

Never heard of it.

I watched a couple episodes of it. I never quite got into it but I can see how it’s just a matter of taste and a lot of people could like it.

JOSÉ: Yeah, it’s awesome. It’s different. It’s a very silly humor but it’s super funny. There’s a lot of potty mouth in there. So, guys will probably like it, some of you.

[Laughs] And some of us will like it but refuse to admit it. [Laughter]

I think the whole series can be summed up with the sentence ‘be careful what you wish for’.

I’m still laughing at Josh’s thinly veiled, “Oh well, lesser humans might like that.” [Laughter]

Or greater humans! De gustibus non est disputandum.

JOSÉ: Yeah, that’s it.

I’m still shopping for underwear. That’s awesome.

You mean, Unerdwear?

Yeah.

José, are you going to be speaking at any conferences coming up this year?

JOSÉ: Good question. So far, just in Brazil. We have Ruby Conf Brazil. I will be talking about Elixir there. And you guys are going to LoneStar. I think Dave Thomas will be there too talking about

Elixir.

That’s right, he will.

Cool.

Thanks for coming on the show again, José. It’s always great having you on.

Yes.

Yes, thank you.

Let us know when you’ve written another language.

JOSÉ: Okay.

We’ll have you back again.

Alright. Well, we’ll wrap up the show then. We’ll catch you all next week.