Post by unknown Post by unknown Post by unknown
I'm sad to see Misultin go, this was in my opinion the only other project
that had enough
momentum to introduce innovation in Erlang web servers.
I'm sorry if you misunderstood this but you also provide the reason why I
have that opinion.
Post by unknown
Yaws exists and continues to exist because people continue to use it
in real-life production systems. Klacke, Christopher, and I all have
day jobs, so whatever time we put into yaws is based on what users are
Misultin and Cowboy are still at a point in the projects' life where
features continue being added or improved before users request them, not the
other way around. They can also afford to break the API a little if a better
solution exists, since both of them aren't considered stable at this point.
That's all I meant.
Sorry but a) I don't see how you expect anyone to be able to derive
this interpretation from what you originally said, and b) this still
has nothing to do with innovation. Do you equate innovation with
greenfield development? You have to break APIs just to innovate? If so
that's awfully misguided.
I suggest studying the work of Clayton Christensen and his Harvard
Business school colleagues, as well as others such as Geoffrey Moore
and Steve Denning if you want to know what innovation actually is.
When it comes to innovation, Scott Berkun, author of "The Myths of
I do use innovation in the disruptive sense, but it seems there is a
bigger issue at hand than my poor choice of words.
Post by unknown
Fact is, plenty of innovation has occurred in Yaws over the past few
years. When I added process-based streaming, for example, it enabled
long-polling apps and served as a basis for websocket support. It also
allowed me (in my day job at the time) to integrate Yaws with a
proprietary hardware TCP offload engine for video delivery, notably
without any special patches or changes to Yaws itself. Innovative? You
bet. Christopher Faulet added a number of small features over the past
year that are incredibly useful to anyone using Yaws in production.
Even just adding rebar support to Yaws led to several innovative
changes within rebar, making it cleaner in spots. I added support for
the relatively recent HTTP PATCH verb to Yaws even though nobody asked
for it, simply because it's in the spec. We even occasionally slightly
broke interfaces to make improvements. And we intend to continue to
innovate, through Yaws 2.0 and beyond.
Please don't take this the wrong way, as once again I mean no harm.
I never heard about all the recent changes you mention. I don't follow
closely any of the server projects, due to lack of time, yet I heard
about all the developments happening in Misultin over the past year from
different sources (announcements, IRC, twitter mostly), up to the 0.9
version. For Yaws, I saw a release announcement a couple months ago, and
sometimes someone mentions it on IRC (always the same set of people
though). Evidently Yaws had websockets for a long time, yet people got
excited when I added them to my then 2 months old server as if it was
the only server that could do them (alongside Misultin, Websocket
support was added back-to-back in both projects IIRC).
This is bad because unless people talk about what your project can do
then people new to Erlang won't know it. I'm relatively new to Erlang
and when I looked for a web server initially I didn't hear about Yaws. I
heard about Webmachine (then found out it used Mochiweb internally, I
didn't hear much about Mochiweb specifically) and Misultin. I did take a
look at Yaws eventually, but I didn't hear much about it. There's an
increase in newcomers to Erlang, and if these newcomers don't hear more
often about what Yaws (or any other established project) can do and
where it's going, they won't consider it. Call it buzz or hype or what
you want, but that kind of communication is important if you want to
grab newcomers. All the veterans use Yaws, yet none of the newcomers, or
at least none of the ones I talk to, know about it. Something there is
wrong and should be fixed.
I hope I explained myself clearly this time and that it won't anger you.
If it does though I'll leave it as that. ;)
Post by unknown
As I said at Erlang Factory London 2011 and in my keynote at the
Erlang Workshop in Tokyo last September, my personal opinion is that
nobody should be writing new Erlang web servers. Every new
"lightweight" "library" web server eventually just gains weight to the
point where still another new project pops up to build something more
lightweight again. If you think something like this won't eventually
follow Cowboy, you're dreaming. But all these new web servers just
splinter the Erlang web development community IMO, and they result in
multiple efforts all having to implement the same support for the same
features, all in different non-reusable ways of course. If people want
to contribute they should instead be working either within existing
projects like Yaws, or perhaps better yet, within Erlang/OTP itself,
in both the Erlang code and the C code, to improve scaling and
performance at that level. Speed up the HTTP parsing within Erlang,
for example. Consider what the OTP team continues to do with multicore
performance, or what Scott Fritchie is doing with dtrace integration.
Doing stuff like that raises all ships -- all Erlang applications,
whether web-focused or not, benefit from such efforts.
I for one hope that more servers appear and try out entirely new things.
I'm saddened to see Misultin go, and would feel the same if Mochiweb or
Yaws development stopped, because I think there is a bigger benefit in
having many projects instead of one. Each project has different goals
and this leads to quite different designs, that other projects can learn
from. I'm hopeful that one day someone will start yet another webserver,
even if just as an experiment, that can showcase a new way of improving
the existing software stacks.
And I'll add that if the improvements are big enough I'll gladly pull
out a new Cowboy version to add them to my project, even if it breaks
some compatibility, as long as it's in the project's scope and furthers
When Cowboy initially appeared a lot of exchange happened between
Roberto and myself about ways to improve both projects, and that's
something I feel is very important. What's more important though is that
even if one project thinks one way of doing things is wrong, the other
can still do it. And maybe it was a good idea and it should stay, but
needed to be proven over time. I'm not sure how you can get this to
happen if you have a single project for the whole community. You can
fork, sure, but if changes are disruptive enough you just end up with
two projects again.