Erlang, Elixir, Blockchain & Serverless... Wait, What?

Join Eric Johnson, principal developer advocate at AWS Serverless, as he takes a deep dive into the BEAM languages Elixir & Erlang, along with the help of two experts in the field Saša Jurić, a well-known, independent Elixir mentor, and Ulf Wiger, first paying customer or Erlang and senior specialist in the architecture and design of carrier-class systems. They explore the relationship between the two languages and when they should be used, and they focus on specific use cases such as Erlang in blockchain or bringing the two languages into the serverless space.

Intro

Eric Johnson: Thanks for joining us here. This is the GOTO conference in Copenhagen. My name is Eric Johnson. I am part of AWS. I'm a developer advocate for AWS, but today I'm acting as an interviewer so we're gonna have some fun with that, and I want to introduce you to my two guests. I'd like you to introduce who you are, and where you're from, and what you do. We'll start with you, Saša.

Saša Jurić: My name is Saša Jurić. I come from Croatia, and I work as an independent Elixir mentor. I am helping teams adopt Elixir and work with it in production.

Eric Johnson: Alrighty. And Ulf?

Ulf Wiger: My name is Ulf Wiger. I'm from Sweden. I'm an independent contractor, mostly Erlang, and, well, I've been programming Erlang since... since, well, forever. Since '92, '93 — since '95, it's been around.

Erlang’s first paying customer

Eric Johnson: It was like the first language ever.

Ulf Wiger: Yes.

Eric Johnson: Just before Latin. Yes, Merlin's pretty old, isn't it?

Ulf Wiger: Well, it pretty much-started life in '87? I would say '92 was the first time it became visible to anyone outside Ericsson, more or less. So I just happened upon it then I was taking a course at the Royal Institute of Technology in Stockholm, and they] were there giving a course about computers and telecommunications, and then they introduced airline and so we got to do a little programming exercise where they had us write the sort of the control program for telephony switch, and then actually have it work first in a simulator, Then on a real phone switch, and that was like a weekend exercise and I was in complete awe. I've been hooked since.

Saša Jurić: So you're one of the first users of Erlang. When you think about it, right?

Eric Johnson: Sounds like it.

Ulf Wiger: I think I was the very first commercial customer because I ended up paying 1000 bucks for a license in '93. I don't know that that makes me the stupidest programmer ever but…

Eric Johnson: I have a couple of languages I'm willing to sell you as well.

Ulf Wiger: Yeah, there are a few.

Eric Johnson: Yes.

Ulf Wiger: There was a plan. We were forming a company in Anchorage, Alaska, and of course, being from Sweden, I have this slightly strange relationship with INS. They were perhaps not so much aware, but we had to figure out a way for me to legally work in the US. So, we decided to make a real strategic bet on Erlang. It made technical sense, mostly. 

I thought that's all that matters. But then we bought them a license when we started pestering Ericsson to say, okay, what is your story on support and everything? We want to bet on early and they were just starting up this company to sell Erlang, so I was their very first customer.

Eric Johnson: That's crazy.

Ulf Wiger: The immediate value was we had to advertise for Erlang programmers in Anchorage and we found exactly one, predictably.

Eric Johnson: It's a one-to-one language.

Saša Jurić: I was expecting to zero, more or less.

Ulf Wiger: I got my H1B Visa out of it, so.

Eric Johnson: Well, there you go. That's a win-win.

Ulf Wiger: Yes.

Eric Johnson: Wow.

Ulf Wiger: I was pretty happy.

Is Elixir the next generation of Erlang?

Eric Johnson: Now Saša, you do Erlang as well.

Saša Jurić: I do now these days, mostly Elixir, but I started with Erlang almost 10 years ago.

Eric Johnson: All right.

Saša Jurić: I don't know how much familiar you are, they're basically like different languages running on the same runtime or the same virtual machine, Erlang, of course, being the very first language running on the Erlang virtual machine, unsurprisingly, and Elixir came to happen, like a lot later. The first version was released in 2014 but José Valim, the creator, started working on it in 2011.

Eric Johnson: So would you call Elixir an advanced version or the next generation of Erlang?

Saša Jurić: It's a really interesting question. Yes, I think that at some point I remember hearing Joe Armstrong, the inventor of Erlang saying that it's like the child of Erlang. So, yes, it's an evolution in some sense, it's definitely like the next generation so to speak it takes in all the good stuff and a lot of the best stuff in Elixir is based on Erlang. It comes from Erlang, not Elixir itself. Many will tell you that the best thing about Elixir is Erlang.

Eric Johnson: Okay.

Saša Jurić: It's like icing on the cake, so to speak. But I mean, Erlang has been designed like in the early '90s and I believe it will have been around much longer. I believe it's pretty much stable for the longest amount of time. Things have progressed, in some sense, mostly in terms of ergonomics that we as developers want. 

My impression, for someone looking from the sides, is that it shows a volume like applied some of these new ideas and techniques from different kinds of languages, using both Erlang as inspiration, but also Closure and Ruby, and even some stuff from the .NET world to improve the UX of language, but still, in its core, it's like Erlang. I heard someone saying that it's almost like Erlang++.

Eric Johnson: Yes, that's complex, right there.

Saša Jurić: Yes

How to choose between Erlang and Elixir?

Eric Johnson: So let me ask you this. I sit down. I'm given Erlang, I'm given Elixir. Why do I pick one over the other?

Ulf Wiger: Well, I would say that it depends. It depends a little bit on what you're trying to do because I think one thing that Elixir brought to the Erlang community was that, for example, web developers. After all, it attracted a lot of people who loved Ruby but were not so much in love with the scalability story of Ruby on Rails, so suddenly, they find this platform where scalability is just amazing. Where you can build conversational web services. 

Now, the Erlang community is very much into carrier-class, fault tolerance, building robust servers, messaging durability, but if you're kind of a UX guy, for example, Erlang is kind of an unimaginative community. People don't care about UX. I mean we had... you're old enough to remember..

Eric Johnson: Probably barely whatever you're gonna say..

Ulf Wiger: These stupid BIOS for the PC know the keyboard missing? Press F1 to continue? At Ericsson, when we .got our first built, or custom-made blades for our system, they have that BIOS bug. So we built them up and said, "Keyboard missing, press F1 to continue," they were never meant to have a keyboard. So we had to send them back. The BIOS was fixed. Erlang systems were never designed to have much of an interface. They were bedded systems, messaging systems, and you would have some developer using HTML just for configuration management, essentially.

Eric Johnson: Yes.

Ulf Wiger: So, it was always very difficult to get any kind of UX story going in the Erlang community because people didn't care. You couldn't get the momentum.

Eric Johnson: It was the purpose…

Ulf Wiger: Yes, it wasn't very nice that somebody else gets to flesh that out and put all the... do the heavy lifting to make it usable, but if you can make it usable, I'll probably use it when I need, which is not very often. So, I see that scene where Elixir is much, much stronger.

Eric Johnson: Saša, what do you think?

Saša Jurić: Yes, I think that's what a lot of... as a quick background, I did like few years of Erlang, a few years of pure Elixir, and somewhere in between both of them.

My impression is that Elixir is both a language, which is more expressive and more complex, and Erlang is simpler and more direct to the point in a very, very explicit language.

It raises a lot of questions about where on the slide from simplicity to the complexity you want your language to be, and so Elixir is geared more towards being more complex language.

I think that the grammar of Erlang is very simple. It's a very regular language, with no special cases, no ambiguities. A couple of those, for example, exists in Elixir and so like Erlang is straightforward. People get intimidated because it looks like a prologue, but when you get past that initial impression, it's a very, very simple language. But for me as a user, I had problems dealing with boilerplate and repetition and stuff like that because the language itself doesn't give us too many tools, and Elixir introduced some of the features in the language, which made things much easier than they would be in Erlang. 

That's my personal impression, and I believe that people who are.... because we're not all equal, right? So there are people who prefer explicit over maybe more expressiveness and the other kinds of people who, like me, may prefer to be a bit more expressive.

Eric Johnson: Right.

Saša Jurić: It depends on your preferences. But, as I said earlier today in my talk really... what comes from the runtime, this concurrency model that Erlang gives us, and every other language on top of being a user, this is really where the key benefits are.

Eric Johnson: Got it. Makes sense. So my only experience with Erlang is many years ago in a previous job we were doing RabbitMQ.

Saša Jurić: Ok.

Eric Johnson: You had to have Erlang installed from my understanding, I didn't know it was almost the networking piece of RabbitMQ that will allow the connectivity. So that was interesting. I learned enough to install it and make the settings and call it good. 

GOTO Copenhagen talks

Eric Johnson: We’re here in Copenhagen, and we're in GOTO. Saša, we'll start with you this time, what are you going to be speaking on? Or what have you been speaking on?

Saša Jurić: Yes, I held a talk which was literally about the runtime layer of Erlang, the BEAM, the language, the official implementation of the Erlang virtual machine, and it was like a demo driven talk trying to showcase why would you want to consider using these languages such as Erlang, Elixir, and there are like 15 languages or so built on top of BEAM for building your software systems. When I say software system, I mean like any back end, any web server, of any kind of domain, and I believe that BEAM is designed very, very nicely for that particular type of problem.

Recommended talk: GOTO 2019 • The Soul of Erlang and Elixir • Saša Jurić

Eric Johnson: Ok.

Saša Jurić: That's what I try to explain in the talk, as much as you can in 45 minutes.

Eric Johnson: Nice. Were you live demoing?

Saša Jurić: There were a lot of demos. Trying to make things more tangible and more, more relatable.

Eric Johnson: That's always fun.. live demoing. See, pray the Internet's gonna work. Right. Yeah. It's all that kind of stuff.

Saša Jurić: Yes.

Eric Johnson: Very cool.

Saša Jurić: The trick is not to base your demo on the network, otherwise you can…

Eric Johnson: That's right. Yes, that's right. Well, I get... as an AWS serverless guy, I have no choice, yeah. So you hope the Internet's working? Oh, what about you?

Ulf Wiger: Yes, my talk is going to be about using Erlang and blockchain development because that's what I'm currently into on the core team of the æternity blockchain, which is a little bit special, maybe not the best-known blockchain of Bitcoin, but it is, as most people know, there are a lot of different cryptocurrencies out there, but most of them are essentially spin-offs of either Bitcoin or Ethereum. 

Recommended talk: GOTO 2019 • Building a Blockchain in Erlang • Ulf Wiger

So, the Eternity blockchain is a project to build a new blockchain from scratch, trying to incorporate most of the things we've learned in the last couple of years of blockchain research, and making a lot of the interesting sort of add-ons that are sort of tacked on on top of, for example, Ethereum, as first-class objects on the chain, and see where that takes us.

That is implemented in Erlang and it wasn't my choice.

Why did you choose Erlang for a Blockchain implementation?

Eric Johnson: Okay, I was going to say. What was the driver on that?

Saša Jurić: I think there are a couple of different blockchain implementations done in Erlang and Elixir. It's like a frequent choice.

Eric Johnson: So why have you chosen it? Why not Node? Just kidding.

Ulf Wiger: My personal feeling about why a certain language is chosen, to begin with, usually comes down to what your experts at the time felt that they either wanted to always program or what they wanted to experiment next. So if it works, well, you come up with a story to justify why you picked the language and why it was the perfect pick and, but usually,

Essentially, we all have our favorite languages that we try to squeeze any problem into more or less. That sounds more stupid than it is because…

Eric Johnson: It's life though., I agree with you.

Ulf Wiger: So in earlier incarnations of this talk, I used to start by basically asking just what's the best language for poetry? Well, that's a good measure of whether you actually can master a language. If you can write poetry in it.

Eric Johnson: When you said that, the best language for web editing. The best language for poetry, so with... that would be Texan.

Ulf Wiger: Yes.

Eric Johnson: Exactly.

Ulf Wiger: I used those slides because they're already on the internet. The answer this time would have been Danish, of course, but…

Eric Johnson: I've failed to agree with that. So...no, maybe so. I do like the Danish language. It's pretty amazing.

Ulf Wiger: There is some amazing Danish poetry.

Saša Jurić: Is there any poetry written in Texan?

Eric Johnson: There is, yes. How are y'all? How are you doing? Got things are brewing. Right off the top. Right there, folks. Wow, that's double. Eric Johnson earned his money today. 

Ulf Wiger: I mean they drive the point that the best language to write poetry in is probably the language that is native to you.

.

Eric Johnson: That's true.

Ulf Wiger: Because it's a way of expressing very complex thoughts beyond the language essentially, and that's where we want to go as programmers as well. So we want to master... achieve mastery in at least some languages and then those will probably be the languages that we are best at expressing very complex ideas in, unless whatever you want to do next fall out of the sort of domain of language that you can very easily solve.

Saša Jurić: Right. Like SQL, for example, right? You cannot, well you probably can write blockchain in SQL, people have been doing everything in everything, but, probably really not like a good fit.

Ulf Wiger: Then, of course, they're unlucky ones or lucky, it would... depending on how you look at it or the C++ programmers, because obviously, you can write anything in C++, right?

Saša Jurić: Yes, you don't feel compelled to move beyond.

Trying to objectify Erlang

Ulf Wiger: Erlang is a little bit more opinionated in that there are certain things that you clearly cannot write in Erlang. As an opinionated language, it should be fairly clear what it's good at and what it doesn't want to do. If you go into a domain where you're using a language, that is very specific about what it wants to be good at, it's gonna fight you every step of the way.

Eric Johnson: Yes.

Ulf Wiger: A lot of people who come into Erlang for example, who are ex-Java or Java programmers, or have only done object-oriented programming, will spend like half a year…

Saša Jurić: That was me.

Ulf Wiger: But hopefully…

Eric Johnson: Trying to objectify Erlang?

Saša Jurić: Yeah, literally, literally.

Ulf Wiger: I did that, too.

Eric Johnson: It's a square peg, round hole type thing, where…

Ulf Wiger: It's fine. You...you...you'll get over it and you decide that…

Eric Johnson: Or you move on.

Ulf Wiger: Not only is it not necessary, but it also is not going to work out well.

Running Erlang or Elixir serverlessly?

Eric Johnson: So I got a question for you guys. Do you think you could run Erlang serverlessly?

Saša Jurić: Serverlessly?

Eric Johnson: Yes.

Saša Jurić: Oh, it's on someone else's server.

Eric Johnson: Yes. What do you think?

Ulf Wiger: I think that it's not going to be a good fit.

Saša Jurić: Yes.

Recommended talk: GOTO 2019 • Building a "Backend-less" URL Shortener • Eric Johnson

.

Ulf Wiger: Actually, when I was at Erlang Solutions some years ago, I was their CTO for a while. We had a lot of talks about whether you could build a cloud environment to execute Erlang Code.

I think we pretty much shelled the idea and decided that Erlang is really good for building rather than executing other pieces of code.

Saša Jurić: I was just going to say that you can run Lambda on Erlang.

Eric Johnson: Yes.

Saša Jurić: You should talk to your people when you come back to the office as you should…

Eric Johnson: Yes, everything you know, this doesn't seem to be working. Oh, wait, it is working now. Nah, I'm just kidding. So, what about Elixir?

Saša Jurić: Elixir's just a different language on the same runtime. So, it's the same story.

Eric Johnson: I would tell you…

Ulf Wiger: No, the thing that's going to trip you up is that Erlang and Elixir, the BEAM environment are very... basically wants to treat processes, almost like object-oriented languages would treat objects. 

Saša Jurić:: Everything is a process here.

Ulf Wiger: Everything is a process that is sort of naturally a concurrent activity or sort of a sequence in a concurrent problem and it should be dirt cheap to create a process. So, you should be able to create as many processes as you want.

Eric Johnson: Right.

Ulf Wiger: So, you know, spawning a process in Erlang takes like a microsecond, and you assume that it's not going to take more. If you want to fire up to handle one session, fire has 10 different processes that each handle a certain part of the problem. Then maybe on the other end of the, you have 10 more, so maybe you have 20 plus 10, 20 processes for one session. and you want to handle 30,000 sessions or more in one Node, that's a lot of processes. 

It's not a whole lot of processes for Erlang. You can have millions of processes in an Erlang VM but the assumption is that it's extremely cheap to send messages and to spawn processes locally. Then if you go across the network to another Node, you have other failure conditions and you also have more costly messages because it's over TCP and you assume that you're actually going to a different machine but when you design code in Erlang, you actually... so you have this local domain where things are local and... and communication doesn't break between processes because they're in the same VM, and you... that's just an invariant. 

Eric Johnson: Yes, exactly.

Ulf Wiger: Yes, it just doesn't happen. When you go across the network, then you deal with network issues, and your code has to deal with that. So at some level, Erlang and Elixir have distributed or location transparency, so you really don't have to worry about where a process resides, or the network. But in practice, you often actually want to have a clear interface between Nodes so that you know that if communication goes across nodes or whether it's locally. 

I guess in a serverless environment, it's a little bit difficult to know how you would view processes and the cost of communicating between processes. I mean, essentially that affects your entire design.

Saša Jurić: If you talk about Lambda, right, which I presume is at the core of the serverless, you spin these instances a lot and take them down very frequently. BEAM takes some significant time to boot up. I mean, we're talking about milliseconds, but still, you know, you don't want to do this too frequently. So it kind of defeats the purpose.

Eric Johnson: Yes, it was kind of a trick. Not gonna lie, it was a little bit of a trick question because we actually have, this was not meant to be a pitch for AWS but I'll throw it out anyway. 

What we have is a custom run time where you can actually bring your own language, and interestingly enough, there has been in the wild one for Elixir and Erlang created.

Saša Jurić:: That's cool to hear.

Eric Johnson: The idea and I see what you're saying because Erlang and.. you mock and laugh at me and say, "Wow, you're dumb," but my understanding kind of Erlang is it is important to have that community... it's part of the networking between process, so it's really designed to go across computer cross and things like that. Whereas Lambda is a stateless encapsulated environment, right? Boom, it happens and it goes away. But if you want to use the Elixir language and things like that, it is absolutely possible. So it's kind of interesting, but I understand what you're saying. Possible, is that same as probable or it's a... may not be the best approach, but it is something you can do still.

Saša Jurić:: I mean, I was just only half-joking when I said that you can like implement Lambda on top of BEAM, on top of Erlang or Elixir, but people have done it too, when they need to, they have the smaller cluster of say, three to five Nodes, when they have to fire up some background activity, they fire it up somewhere. It's a short living process, a task, does the job and stops, which runs either here or there. You don't really care which machine it's run.

Eric Johnson: Right. Right.

Saša Jurić: Like distribution is a first-class citizen in Lambda. That's why I believe that it's like an interesting fit for blockchain right, which is also distributed in its nature.

Ulf Wiger: There are two different aspects that are in this case, I think important to keep separate. One is you have sort of the core semantics, concurrency semantics of our language, I think are a great fit for that kind of environment where processes have their little life thread essentially, and they have their own memory, they communicate asynchronously, they can monitor and link to each other so you can actually build sort of a self-healing and self-cleaning environment.

Saša Jurić: It's distributed from day one, right? Even on a single machine.

Ulf Wiger: But then you have the practical implementation of Erlang, which, as Saša pointed out in his demo talk, excellent talk, is very much about the BEAM. The BEAM VM and how it works and also, here we have the reason why Ericsson built it in the first place. They wanted to experiment with how you should program the next generation of telephone switches. So then that was their problem domain. It's very nice to have a very concrete problem domain.

Eric Johnson: Yes. Oh, yes. Here's the solution. 

Ulf Wiger: What they had then in practice was that you essentially have your control system that's an orchestration problem. Essentially, you are doing signaling crossing with other entities on the network, and then you are allocating .resources in the hardware switching you're forwarding engine resources or signal processors, whatever, to link together so that you have it in the data plane, you have all the niceties that you need with transcoding and echo cancellation and everything. 

Then you have these processes in Erlang that actually had a fairly intimate connection with the hardware because you wanted this VM to sit there and actually control certain hardware pieces and then you had the redundancy and also, no sandboxing obviously, you know, this is TelCo. You have big locks on the door.

Eric Johnson: Yes.

Ulf Wiger: We thought at least we sold one switch to the Stockholm region and there were some debug ports open on the device processors switch.

Eric Johnson: That's no bueno.

Ulf Wiger: It turned out some high school students were sitting there, you know, what you typically do running open telnet ports. Let's see if we can do it.

Eric Johnson: Yes, of course. Wow.

Ulf Wiger: So, they would just tell it into the device processors on our switches, and there went the assumption that well, these operators, they run safe networks.

Is Erlang an Ericsson language?

Eric Johnson: Yes, exactly. Unless you have high school kids around. So let me ask you, this is a critical question. Is Erlang an Ericsson language?

Ulf Wiger: Yes. Or…

Eric Johnson: Not just a pretty face, people.

Ulf Wiger: It's not... it's an intentional duality.

Eric Johnson: Okay.

Ulf Wiger: Yes, that's one obvious interpretation that is wrong…

Eric Johnson: Ok. Oh, wait. Are you saying it might be wrong?

Saša Jurić: Yes.

Ulf Wiger: Yes. Well, so there is this tradition to name languages after mathematicians. I'm gonna call Erlang. Forgive my poor Danish pronunciation. He was a Danish mathematician, and he was extremely important for Telco because queueing theory is basically, based on there's even a unit of measure in Erlang, which is you measure the frequency of subscribers or customers coming to a service desk or whatever. So, it was named after Erlang, but it so happened that you could

Eric Johnson: Ericsson language.

Ulf Wiger: That was... it wasn't entirely unintentional.

Eric Johnson: Ok.

Ulf Wiger: So, but it's the secondary…

Eric Johnson: So, I was unintentionally 50% right?

Saša Jurić: According to some people, and all of them were Danish, it's been named after Agner Krarup Erlang and a syllabic abbreviation of "Ericsson Language".

Who would win between Erlang and Elixir in a wrestling match?

Eric Johnson: Another critical question. In a sumo wrestling match, who would win, Elixir or Erlang? And why?

Saša Jurić: I believe they wouldn't compete because they're lightweight.

Eric Johnson: Wow. That was the best dodge I've ever seen. Guys, I really appreciate you joining us. This is a lot of fun. I'm gonna be honest. I've learned more in this session than I thought... than I thought I would. But I really learned... I knew of Erlang, I knew of Elixir. I didn't know how they were related. I didn't know their purpose. I didn't know why anybody would use them. And now I know, and it's actually quite fascinating. But Sasa, Ulf, I appreciate you joining us and I don't know if you want to give a "Hello," "Goodbye," "Hi, mom," anything like that, but thanks a lot.

Saša Jurić: Well, thank you for having us. Yeah, it was a... it was a blast.

Eric Johnson: You bet.

Ulf Wiger: It was fun. Thanks.

Eric Johnson: Yes, thank you. We'll see you later. And we're out.