[erlang-questions] Misultin EOL

[Steve Vinoski]

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/

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.

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.

--steve