Totally Erlang Superhero cowboy: Loïc Hoguin
You don’t look like a cowboy!
People say that all the time, because I keep forgetting my hat. But I do have one! I don't look much like a cowboy though... Probably because I spend so much time working on my projects.
You probably wonder why the name Cowboy? Well there's this other project called Apache, so Cowboy just seemed like a fun counterpart.
So actually you sit behind a computer screen like the rest of us. What is it that you do?
I write open source Erlang! That's what I do both for fun and for a living, through my company Nine Nines.
Nine Nines was created late 2011 to provide services around the Cowboy ecosystem and Erlang. Recently we have been working on the open source project LeoFS and are adding SPDY support in Cowboy for use in LeoFS. We also occasionally do consulting and Erlang training when requested.
Where do you usually live and work? On your site you offer services anywhere in the world. How does that work?
I live in a small town called Libourne in the south of France. It's a pretty sunny place. I'm not used to dealing with rain or umbrellas. I go biking on a regular basis. In the summer I got to the beach an hour away, and the mountains aren't too far either.
I'm probably the only Erlang developer in town. But that's fine, most of my work is done online, I can work from anywhere. And the airport isn't far if I need to go to the other side of the world.
You’re spending a lot of time giving talks and building open source technology. Do you actually earn any money?
I write software for fun, release it, then talk about it online and at conferences. Some companies start to use it, but find that something specific is missing for their use. They can then either tell me about it and hope it'll be implemented a few months later (it can take a while!), go through Nine Nines and have it available in at most a few weeks, or write it themselves and optionally send a patch.
Consulting goes a similar way. There's a lot of companies who start using Erlang these days and they have one or two guys learning the language and trying to build a product, often based on Cowboy or Ranch. Doing that by yourself can take months before you get it right, especially because of the OTP step. Using our consulting services it only takes two or three days to convert your pure Erlang prototype to OTP, giving you a lot of advice in the process and of course correcting any obvious mistake along the way. Later on you can also call us back if you want to optimize the hell out of your product.
What got you into Erlang in the first place?
I used to write PHP for a living. Regardless of the language quality, it was very good at doing some web related work, and very bad at doing more realtime web work. So I occasionally looked for alternatives. And then I found Erlang, didn't try it, and went back to work.
Later on I was involved with a community of people who wanted to revive a dead online game after the US servers got killed. Erlang seemed like a great fit. So I started learning it. It took a while. At the time LYSE was only 5 or 6 chapters long, so I mostly used Joe's book (TW: Programming Erlang: Software for a Concurrent World) and some of the few blog posts on the web.
At some point when developing this project I wanted to be able to have some mechanism to handle any kind of protocol in the same application easily, and that concept became Cowboy and was then split off into Ranch.
That project is now sleeping, in part because we're stuck at understanding a key part of the protocol for the game, but also because the code was too tedious to write without maps support. It might be revived if they ever make it into Erlang.
I understand you only committed the first version of Cowboy in 2011. What made you decide to build a webserver in a world full of webservers?
It's a combination of things. There seemed to be demand for a server that uses binaries instead of lists, that was "clean", not using parameterized modules or the process dictionary; it was a continuation of the Ranch concept I had in mind; it seemed to be fun. And it was both fun and an awesome learning experience.
What is Ranch being used for?
Ranch implements the TCP acceptor pool, transport abstraction and supervision of all connection processes, so that developers can just focus on writing the code for the protocol they are implementing. Cowboy is an HTTP protocol implementation on top of Ranch. Ranch can be used to write an implementation for any existing TCP protocol, or even custom ones. It is our second most popular project and receives the same level of support as Cowboy.
How does Cowboy relate to other webservers like Apache, Microsoft IIS and more specifically the other Erlang based webservers Mochiweb and the discontinued Misultin.
Most servers are based on or similar to Apache. The general idea is to map requests to files and execute these files. Cowboy is more like Mochiweb or Misultin. They don't know anything about files, they map requests to Erlang modules.
Cowboy is different than Mochiweb or Misultin mostly for two reasons. First, it uses binaries everywhere instead of lists. This mostly allows us to save memory. Second, it uses a single process per connection instead of two. This again saves memory and avoids too much process communication, at the expense of having to keep a little variable around.
Now Cowboy and Erlang in general is famed for it’s speed. Is there real proof in the form of bench marks for this?
You know what they say, "Lies, damned benchmarks, and statistics". Benchmarks rarely test what they say they are testing. They also generally aren't representative of how the system will behave in production.
Recently I did some optimization in Cowboy that made absolutely no difference in benchmarks but had a huge impact on production systems, allowing servers with the new code to take on twice as many requests as the servers with old code. These are the things you want to optimize, not benchmarks. I will probably publish a benchmark in the coming months though. But not your usual benchmark. I got a few cheap servers at home and I want to show the number of connections you can get from Cowboy out of these things.
Because that's what Erlang's strength is. Erlang isn't made for throughput, but for low latency concurrency. And there's no good benchmark for that yet, because while the rest of the world is focused on solving the C10K problem, Erlang has already solved the C1M problem long ago.
Do you have any idea how many servers are running Cowboy? How do you keep track of that?
My guess is a few tens of thousands, for a large definition of "servers". Cowboy is not just used in servers, but also in set-top boxes and a variety of other devices. It's hard to track.The number of watchers on Github is nearing one thousand as we speak, and I see many new users on a regular basis, so I'm not too worried. The project is healthy and things are looking good!
What are the really big implementations you know of?
A very interesting use of Cowboy has been documented here: http://ferd.ca/rtb-where-erlang-blooms.html and they have been instrumental in improving the performance of the server.
My SF Factory 2013 talk lists a few more implementations on slides 32 and 33. http://ninenines.eu/talks/cowboy-0.8/cowboy-0.8.html
Do you actively support a lot of these implementations? How does that work?
Most companies seem to be able to use Cowboy without active support, relying only on the source code and documentation. This is very important to me because that means we got a lot of things right.
What are the plans for the near and more distant future for Cowboy? Should people outside of the Erlang world be interested?
We are in the process of making the API stable. The first version of the function reference has just been released, immortalizing the API that is going to be in version 1.0. At the same time there is a lot of work going on adding SPDY support. An experimental version of this is about to be released as I write these lines.
After 1.0 we will focus on improving the performance and documentation. Then in the far future, Cowboy 2.0 will probably come out around when HTTP/2.0 gets implemented in popular browsers.
People outside the Erlang world usually start using Cowboy for its Websocket support, and often fall in love with Erlang and continue working with it; or at least try to convince their company to let them. I'm hoping this trend will continue with SPDY and HTTP/2.0, as most legacy web servers are absolutely not designed with the asynchronous features of these protocols in mind. Erlang is asynchronous by nature. It only makes sense to use it.
Finally, all the techniques that Erlang and Cowboy allow will be the content of an upcoming book usable by both Erlang and non-Erlang developers. Look forward to it!
(TE: it's not yet possible to sign up for the book, keep a lookout on twitter @totallyerlang).
I understand you’re developing tooling for Frontenders that don’t want to get into Erlang programming. What’s that about?
That would be the Farwest project. The plan is to have a set of libraries for Erlang developers that are compatible with an optional UI that allows non-Erlang developers to access and modify routes, templates, data, files, etc. without having to touch any Erlang code. Farwest also comes with various handlers to facilitate fast prototyping of web applications. And of course once the project is done you can leave some of that UI in so that users can perform all the boring work without bothering you.
We currently are running a fundraiser to be able to pay a UI designer to do all the client-side Farwest work, which is key to the project. Any amount is appreciated!
Good luck with that, and thank you so much for this interview!
Nine Nines: http://ninenines.eu/
Cowboy and Ranch: visit the NineNines site.
Loic is running a fundraiser to sponsor the development of Far West,