[erlang-questions] Misultin EOL

[Loïc Hoguin]

On 02/18/2012 08:55 PM, Steve Vinoski wrote:
> On Fri, Feb 17, 2012 at 10:13 AM, Loïc Hoguin<essen@REDACTED>  wrote:
>> On 02/17/2012 04:06 PM, Steve Vinoski wrote:
>>>
>>> Earlier in this thread we have this gem from Loďc:
>>>
>>>> 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.
>>
>>
>>> 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
>>> asking for.
>>
>>
>> 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
> Innovation", once offered this advice:
>
> http://www.scottberkun.com/blog/2008/stop-saying-innovation-heres-why/

I do use innovation in the disruptive sense, but it seems there is a 
bigger issue at hand than my poor choice of words.

> 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. ;)

> 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 
its goals.

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.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines