I know about that issue and can assure you that once my todo list is done, Cowboy will not get any new feature unless HTTP gets a new version; HTTP gets replaced by something better (Google is experimenting with that); some new kind of long-polling appears that does it better than previously. Everything else will be minor improvements, supporting r15+ Erlang versions, and fixing bugs. So unless something changes a lot in the web landscape, Cowboy will remain the same.

Once Cowboy is done it’ll be a good basis for the rest of the environment I’m building and I don’t plan to add features to Cowboy but rather build other applications taking advantage of it. To give an example, if I ever need RSS, SOAP, XML-RPC, they won’t be part of Cowboy, but rather separate reusable applications that won’t depend on it. Kind of like ex_fcgi does now. That’s the biggest difference in philosophy between Cowboy and Yaws, and I sure don’t want feature creep in anything I make, simplicity is always better IMHO. Where other lightweight servers become more like Yaws, Cowboy won’t, it’ll stay as is until a tech revolution happens.

Oh and don’t worry, if I need SOAP I’ll probably just use Yaws as I can’t care less about SOAP and wouldn’t want to reimplement it even if I was paid to do it. ;)

About the not posting on the ML, yeah I don’t do that unless I use something for a long time. Took me more than a year before talking on Erlang IRC channels or on the ML, and I gave up on Yaws long before reaching that stage. Although I did plan on using it initially before looking at WebMachine.

Great talks by the way, been enjoying the chat.

New users should not be afraid to try to contribute to Yaws. I was a new user a few years ago, and I certainly wasn’t afraid. I liked the stability Yaws gave my project from the start, and yet I could also see where I could add to it. I was then fortunate enough to have Klacke add me as a committer, and I’ve learned a lot from him and from all the Yaws users as a result. Had I instead gone out on my own, I’d have fewer users, assuming whatever I worked on ever saw the light of day at all, and would have missed out on working with one of the greatest Erlang programmers of all time. And that was back when Yaws was in svn — in this day and age of github, there’s really no barrier to contributing to existing projects.

Thanks again for your comments, and I hope we can meet in London and have time to discuss all this some more.

The problem with lightweight systems is that they gain weight quickly as they succeed. This isn’t a technical issue but rather is simply how markets work, and it’s unavoidable. If the software is successful, users demand new features as they discover that “heavyweight” feature supplied by other frameworks viewed unfairly as “too heavy” actually exists for a good reason and is needed for real-world solutions. I think you need only look at the recent history of misultin to see this effect (and that’s not at all a knock against misultin, but is rather simply a product of its success).

You seem to use the term “legacy” as derogatory, yet for many it means “stable,” “reliable,” “mature,” and “something that just works.” “Legacy” implies “successful” since if there are no users, there is no legacy. Anything you release that garners users who deploy your code in production is legacy. It’s a nice problem to have.

I don’t understand the Yaws reputation you claim, since considering all of what Yaws can do, it’s actually not complex at all. For example, if you look at the code in my blog entry above, it’s no more complicated than any of the examples Roberto posted for the other frameworks. Running it in a deployed server requires one extra line of configuration; alternatively, running it embedded requires a few extra lines of Erlang config code, certainly no more than Roberto’s Cowboy example and probably fewer. Have you ever actually written real applications in Yaws? If so, can you provide me details on exactly where the complexity is?

I think a critical point you’re either missing or unintentionally ignoring is one I tried to make clear in my posting: since HTTP handling and socket handling are essentially built into Erlang/OTP, there’s not a whole lot of room for drastic performance differences between different Erlang web frameworks. You say you can build Yaws-like functionality on top of small and fast libraries, which is true but guess what? The end result will naturally include extra overhead due to the additional code, thus negating any slight performance advantages, and it will likely end up reinventing much of what a more complete solution like Yaws already provides. So what would you rather do, use a proven solution that already exists, or just rewrite and then have to debug and maintain the very same code solutions like Yaws already provide? And if you’re going to do that, why not contribute your efforts to an existing project instead of writing a new one?

I’m pretty certain that most of Yaws’ detractors have never actually used it or even looked at it much. I think if they had, they would have been on the Yaws mailing list asking pertinent questions, perhaps challenging some of the current design and implementation, and supplying patches, and I don’t recall seeing that sort of traffic there in recent memory from anyone involved in these newer frameworks. Which is a real shame, because then the reasons for the new stuff end up appearing as nothing more than NIH syndrome, which, as I’ve already hinted repeatedly, leads to community fragmentation and a stagnation of progress in Erlang web development practices — ironically, likely the very opposite of the effects actually being sought.

Speaking of fragmentation, I don’t think any language is really united to begin with. Except the ones with a central and easy to use repository of projects, maybe. And even then, I’m not even sure. It’s normal that people want to start from scratch and reinvent new things to make them “better” (this is often subjective). At worst we learn something. The important thing I think is that new people come to Erlang. The gen_server2 project doesn’t make people stop using the gen_server or refrain them from using Erlang. ;)

About the Rails comment: Rails people were united under Rails. Not Ruby people. The people who thought they needed Rails were pushing for it. Three years later they went on into separate ways, some staying with Rails, others trying to make new Ruby frameworks, and others presumably moved to NodeJS. That’s how long you can keep people united before it completely breaks. I don’t think we can do anything about it. :)

Anyway I will probably try to share all my experiments with Cowboy in Stockholm later this year, and I’ll also be in London next month as a visitor, hope we can get in touch and share some more thoughts there.