Totally Erlang Superhero: Fred Hébert
Picture by Mahesh Paolini-Subramanya (@dieswaytoofast) taken in March 2013 at the Erlang Factory in San Fransisco
How old are you?
25 at the time of this writing.
What? You’re so young! How dare you write a book?
Age doesn’t feel weird, and didn't feel weird when I started writing (I was 21). What really felt weird is that I started writing the book without being an expert, or even especially competent with the language. And English is not my first language. Thankfully, support from the community and all kinds of documentation sources made it possible for me to make something that stands on its own.
I’ve heard experienced Erlang developers rave about the book, so it looks like you did something right. What brought you to start with Erlang?
It was accidental more than anything. I was working as a PHP developer on a dating site, and I got pulled into a tiny R&D department where I was asked to get to learn Erlang and prototype a chat system. The R&D department was 3 guys, one of which sat on the board of the company. He ended up leaving, and the other guy was out for a couple months for various reasons. I ended up alone, with nobody in the company to tell me what to do, learning Erlang until they figured out what was going on.
When they figured out I was doing nothing but playing with Erlang for months in my office, they made me become a PHP developer again. I left a few months after that.
I loved the little drawings in your book. So you’re an artist too?
I don't consider myself an artist. I draw on the side, but would not consider it art. For similar reasons, I don't really consider myself to be an author either. I'm a programmer who happens to write or draw from time to time.
By writing a book you probably compared Erlang to other languages. How does Erlang stand now?
I don't think it has changed much. I think people are generally more aware of Erlang than they were a few years ago, but I couldn't say with certainty that more people or businesses are using it. One thing I can say is definitely nice is that some of the core ideas behind Erlang have been adopted by other languages and libraries, namely in Scala, and Rust. They still likely lack many vital aspects of the language to be able to emulate everything it allows to do, but that’s not necessarily a bad thing. I obviously can't predict the future, but I'm happy if some of the good ideas in Erlang get to leak into other languages so more systems may benefit from them.
Which idea’s do you mean?
Things like attempting to have multiple processes, supervisors or the possibility to have some through links, for example. These things force you to you consider how you want the system to fail when designing it, instead of just hoping it doesn’t happen. And while there is no absolute supremacy in message passing concurrency, these languages still put emphasis on it, which is great for isolation and makes it somewhat easier to write loosely-coupled components.
Features usually not used by other languages end up being soft real time constraints, isolation, immutable memory, and so on. I’m not sure what an Erlang without these constraints would give, but I doubt having partial adoption of its ideas is worse than having none of them.
Why is Erlang better that most languages?
Erlang is better at a few things in a few circumstances, equivalent at other things, and worse at some others.
For example, Erlang has little mutable memory in the sense programmers are used to: no arrays, no O(1) memory updates in there. This means most algorithms learned in university or in most computer science books are no longer valid, and need to be reinvented in a way or another, or to focus on amortized times rather than direct predictability. This makes it hard to use it to write, say, a game engine, which would likely need a good bit of global state and heavy math, which might be far from obvious to write in it, let alone optimize. For that kind of task, it will very likely be worst than other languages that are currently used in the industry.
Erlang will probably be equivalent to languages like Go at various tasks -- the tradeoff might be in how high or low level you need to be, or on whether you plan to go distributed and whatnot.
Then Erlang will probably be very good to you if you are writing servers with lots of users, when you’re dealing with protocols, or need high fault-tolerance principles.
And then again, I also think that as programmers, we tend to forget about the human factor. The success or failure of a project is often related to social factors. Communication between members of the team, or between the team and management, or the team/management and the client can all end up turning a project upside down, and the dynamics of a team can have as much weight as having made very good (or very bad) technical decisions.
Languages are tools, and whether you're able to make use of that tool effectively depends on the person wielding it.
Do you think any developer could convert to Erlang?
Difficulty in learning things depends on your own baggage and also on the training material (or trainer) you have, and how compatible these things are. I don't think Erlang is implicitly difficult, but someone's background or even their reasoning model might make things harder to get started.
What type of background are you talking about?
Well, this is hard to answer without painting people with a wide brush, but there have been some examples I’ve seen. Someone who thinks in objects all the time and fully embraced this as the true way to computing will have to break that mold before making place for a different idea like actors. It can be confusing because the two concepts are similar in many ways, but very different in other ones (inheritance, for example).
The same kind of struggle can be seen when Haskell programmers, very much used to a Hindley-Milner type system as the core component of their development technique, get to use a functional language without that kind of typing. It forces you to separate the types from the functional aspect, and you frequently see them complaining on the erlang channel on IRC.
They have a harder time accepting how things are than someone who has little experience and no development patterns to break.There are other cases, too. Someone who has worked with plenty of languages in different paradigms (say, logic languages like Prolog, functional languages like Lisps, or other “out there” languages such as Forth, Oz, and so on), may find it way easier to deal with the syntax and semantics than someone who has lived in C-derivatives forever.
In general, Erlang is used both by the industry and academia, and depending on where you come from, different material is available to you, with different degrees of formalism or intended audiences.
In your book you say Erlang is slow. What a horrible thing to say! :-) How so?
In most discussions about speed, people have this "as fast as C" criteria. Erlang is very obviously slower than C at cpu-intensive tasks. It's possible to use Erlang for tasks that are usually left to languages closer to the metal, but it's not always easy, obvious, or desirable. The gist of it is that people shouldn't expect a language that is awesome on all dimensions (Erlang isn't one), and I usually want to make this clear early.
Where do you think Erlang will be going in the next five years?
I'm not one for wild predictions. If anything, it will be slightly more popular than now, or slightly less popular than now. I don't expect huge changes in how the regulars deal with the language bar some major event. You'll always have rushes of new users (or departures) when well-seen members of a community start complaining about things, but the core community seems relatively stable.
If you were free to work on any aspect of Erlang, OTP or a framework, what would it be?
I would really like to be able to modernize the shell, and to have the miraculous dependency/build management tool. The other really annoying thing with Erlang is the problem of being able to load only one version of a library at a time. It's a downside of how module loading currently works, and I have a hard time thinking of a simple, efficient, and good ways to extend things without messing up with existing mechanisms. I'm not smart enough to figure it out.
I think a lot of people have minor issues with Erlang, but everyone's still too busy to fix things. There's a general lack of coordination on things like libraries, forks, repositories, and documentation is a huge hit and miss.
To me those are signs of social issues in the community, and remind me a lot of the lisp curse. I think Erlang programmers, as a community, have to be aware of that and should try to work on a solution to that if we want our community to grow.
As a community, we should be moving towards making sure that the technical advantages obtained through using Erlang are not ruined by a comparatively weak or unfriendly social environment due to a lack of coordination from the regulars.
What are you working on at the moment? And can we expect more books?
I’m not writing a book at this time. I have been writing for a long while, and I've been itching to do entirely different things the entire time.
I’m back to the mode I was on before the book. I have a dozen small projects progressing very, very slowly, that may never meet the public eye. Network simulators, dependency managers, patches to get erlang-history into Erlang/OTP, and so on. I also have ideas for a few blog posts that I haven’t worked on enough at this time, too, and a few books to read. Oh and maybe I’d like starting to play music again. I have had to stop since I had so little time. I also want to keep some free time to help my girlfriend with her projects, after she dealt with mine for so long.
Anything else before saying goodbye?
I think I might have sounded a bit harsh towards the Erlang community, but at this point, I mostly have very positive things to say about everyone involved and am always eager to go to Erlang Factories to meet them. The individuals of the community are amazing and impressive people.
You can read or order the book here: