<div dir="ltr"><div><img src="http://static.giantbomb.com/uploads/ignore_jpg_scale_super/4/40549/2635754-trollthreads.jpg" width="395.625" height="480"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">

On Wed, Jun 18, 2014 at 12:02 PM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Okay I wanted to skip this thread entirely but you mentioned Cowboy and said weird things about it so I'll bite.<div class=""><br>
<br>
On 06/18/2014 09:39 AM, Aaron J. Seigo wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
comparing with cowboy, the differences are glaring. for instance, in the<br>
"getting started" guide for cowboy:<br>
</blockquote>
><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* we live in the microwave popcorn and 10-minutes-is-a-long-video-on-<u></u>youtube<br>
age. yet the first FOUR sections are not about cowboy at all, but talking about<br>
the modern web and how to learn erlang. as someone moderately familiar with<br>
the web, i don't care about this. *just let me get started already!* if i'm<br>
reading the getting started guide for cowboy, i probably don't need to be sold<br>
on either the modern web OR erlang.<br>
</blockquote>
<br></div>
I'm not sure why you call it a "getting started guide" all over your email. It's the user guide. It may have one "getting started" chapter, but its goal is not to get people started, but to be a complete guide. This includes not only practical examples but also theory. Why theory? Well everyone coming to Cowboy isn't a web developer, or even an Erlang developer. Some of my users were happy enough that these chapters were in the guide that they contacted me directly to tell me they liked them.<br>


<br>
If you are a web developer, then why are you reading these chapters? Do you read the documentation for every computer you buy? Do you need to learn how to put the power plug in to charge it? You probably don't need that. But some people do, and that's why we put these "obvious" things in the docs.<div class="">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* being a good, modern developer with the attention span of the average<br>
backyard squirrel i simply skipped straight to the "Getting Started" section.<br>
the FIRST sentence is this:<br>
<br>
"Setting up a working Erlang application is a little more complex than for<br>
most other languages. The reason is that Erlang is designed to build systems<br>
and not just simple applications."<br>
<br>
... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], and my<br>
application IS simple. so cowboy is not for me! right?<br>
</blockquote>
<br></div>
Well there's nothing we can do about that. We can't just write one file and run a program on it. That's simply not how Erlang works. We have to create an OTP application, compile, start the VM with the right paths etc. That's not just Cowboy deciding to be more complex than nodejs, that's how Erlang was designed.<br>


<br>
And while it's improving (you should have seen things 4 years ago when I started, the getting started in Cowboy is *immensely* simpler than it would have been then), it'll never be as simple as nodejs. Because most of the stuff in the getting started chapter is necessary as I'll explain in a bit.<div class="">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* the rest of the "getting started" walks me through doing a ton of<br>
boilerplate stuff. it's nice to know how things work, but i'm a busy web dev<br>
(have i mentioned my lack of attention span yet? oh look, a peanut! and it's<br>
an event driven async peanut! yum! *runs off*). everything in that section<br>
ought to be boiled down to "run this one simple command and everything is done<br>
for you. click here to read about the gory details." and doing so should give<br>
me a fully functional application template that i can immediately start. that<br>
one command should probably take a simple config file with things like the app<br>
name and other variable details (such as which erlang apps to include in my<br>
awesome new project, including but also in addition to cowboy). basically, an<br>
npm-for-erlang.<br>
</blockquote>
<br></div>
The next <a href="http://erlang.mk" target="_blank">erlang.mk</a> version will make it a little easier by generating a base project (using templates, as you say). But that will not change the getting started chapter much, as we will still have to explain things. Instead of saying "create" it will say "edit", basically.<br>


<br>
It may sound like a lot for someone with as little attention span as you, but going through these steps saves you an immense amount of time later on. If Erlang beginners start using releases immediately, we win. They will not have to suffer going through hoops like we did to get to that point. They will not have to fiddle with paths, or make start scripts, or deal with complex deployment issues, or anything that we struggled with for years. It *is* a big step, and we probably can't reduce it much more, but it's an incredible time saver.<br>


<br>
But of course impatient people will prefer to waste their time by missing out on it.<br>
<br>
And to be honest if we weren't doing this then we would have to explain how to write a start function, start erl with the -s option and make a start script for frequent use. It wouldn't be simpler, it would just be different, and we would just miss an opportunity to teach beginners "the right way" from the start.<div class="">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
oh, and bonus points if there is a file created just for route definitions which<br>
would then be automatically included by the foo_app.erl to be passed to<br>
cowboy_router:compile. having a "well known" place to define routes will<br>
standardize cowboy using applications and allow the starting dev to focus on<br>
what they care about (routes and handlers) while ignoring the details like the<br>
app module. yes, yes, eventually they'll likely want to dig into that as well,<br>
but not at the beginning. (this is an area that cowboy+erlang could be even<br>
better than express+node.js)<br>
</blockquote>
<br></div>
Cowboy isn't a Web framework. There's nothing to standardize. It's a thin HTTP layer implementing the various HTTP specs. That's it. Yes, routing is also part of the spec, as it is a way to map URIs to resources which is well covered by the spec.<br>


<br>
There's tons of Web frameworks built on top of Cowboy if you want standards. Everything in Cowboy is done by calling a function (or Cowboy calling one of your functions). The application module is simply the only place where you can run code at startup, so we have to cover it. Besides I don't see much difference between explaining how to run code in this module vs explaining the structure of a configuration file (it's harder to do the latter really).<div class="">

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* i couldn't find the bragging section of the docs. ;) more seriously, the<br>
getting started guide tries to sell me on the modern web and erlang's place in<br>
it, but how about a fun little one-pager that backs up the claims made in the<br>
main README: "Cowboy is a small, fast and modular HTTP server written in<br>
Erlang." and " It is optimized for low latency and low memory usage". show me<br>
the money^Hmeasurements! a simple set of charts showing how many simultaneous<br>
connections can be handled and what kind of latencies app the developers<br>
achieve on regular ol' hardware, along with a LOC-you-need-to-write-for-a-<br>
barebones-app count would help convince people and would be the thing that<br>
would get passed around on stackoverflow, g+, twitter, etc. when justifying /<br>
recommending cowboy.<br>
</blockquote>
<br></div>
Would you believe me if I told you Cowboy is capable of handling millions of concurrent Websocket connections on a middle sized server, with *no impact* on latency? And would you believe me if I told you I do not have the slightest idea what the upper limit for the number of connections Cowboy can actually handle *is*? Because that's the truth.<br>


<br>
This is in large part due to Erlang, Cowboy mostly tries to be careful about memory use, and could do a better job at it.<br>
<br>
But still, how do you even brag about a difference that big with other platforms, and make people actually believe you?<br>
<br>
Besides, if you look at the benchmark of the week, they're still all focused on glorified "hello world" measuring requests per second. Cowboy obviously can't compete there, as these are won by JITs not by the underlaying code. Not to mention these benchmarks are the most misleading and useless kind you can ever write.<span class="HOEnZb"><font color="#888888"><br>


<br>
-- <br>
Loïc Hoguin<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a></font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>BR,<br>\|/ Kunthar<br>
</div>