##Interview with Dave Thomas:
It’s been a while since the last revision of this book. Why a new edition now?
I guess it’s been almost 3 years. I’ve resisted doing another edition because not much has actually changed in the core language. There’ve been a few deprecations, and a bunch of new functions, but almost all the code in the 1.3 version of the book runs just fine on Elixir 1.6.
But… it has been 3 years. And during that time the Elixir community has gained a lot of experience. Although the language is pretty stable, the way we use it has become more sophisticated. That’s what triggered me to update the book: I wanted to show some of those new ideas.
Can you give an example?
Let’s look at one of the core components of the Elixir runtime, the GenServer module. This comes from Erlang, and in the past we designed Elixir GenServers just about the same way the Erlang folks did (although the implementations were a lot simpler). But we’ve moved on from that. Elixir has new ways of specifying the supervisors for servers, and new convenience servers such as Agents and Tasks. The result is that idiomatic Elixir has moved on quite a lot. I ended up writing a new chapter, and substantially changing two others, to reflect these new (and better) styles.
In the past, you said that developers should learn Elixir because it teaches them a new way of thinking about code. Do you still feel the same way?
Yes and no. I think that reason is still valid. Apple just shipped an 18 core iMac. Servers with 64 and 128 cores are in the works. You need to find reliable and manageable ways to write code for these beasts. I still firmly believe that functional programming is the key technology to make this happen. On top of that, the actor model seems to be the best way to communicate between processes. And Elixir is both a functional language and it has a runtime library based on the actor model that has been battle tested for decades.
But now I give a second reason why developers should learn Elixir: there’s a well-paying and expanding job market for Elixir developers. It’s a skill that’s in short supply, and this is a great time to join in.
What do you see in the future of Elixir?
I’m more and more convinced that the browser will not be the dominant way we interact with the internet in the (near term) future. You can already see the growth of alternatives: mobile apps, smart devices, and even things like Alexa and Google Home. As computer power becomes ambient, we’ll need technologies that let us deal with this dynamic, long-running, and fault-resistant world. I think Elixir has a big part to play in this.
Already we have the Nerves project, which lets you burn your Elixir applications into free standing images which will boot on devices such as the Raspberry Pi Zero. That’s a $10 processor with WiFi, lots of I/O, and a full Elixir and Erlang runtime. I made a touch sensitive xylophone that uses pubsub to communicate over the ‘net with synthesizers running on desktops, both client and server in Elixir.
And that brings me to the second revolution. Elixir has a framework called Phoenix. Unfortunately, people see it as some kind of Rails replacement. But Phoenix is way more that that. Phoenix is a connectivity framework. If it connects to the ‘net, Phoenix can talk to it, switch traffic to and from it, and manage it. It’s a natural for driving millions of IoT devices from a single server.
So I see the future of Elixir as being the future of software. And it sounds like fun.
By the end of this book, you’ll understand Elixir, and know how to apply it to solve your complex, modern problems.
).
