[erlang-questions] node.js vs erlang

[Aaron J. Seigo]

On Wednesday, June 18, 2014 11:02:13 Loïc Hoguin wrote:
> Okay I wanted to skip this thread entirely but you mentioned Cowboy and
> said weird things about it so I'll bite.

s,weird,typical first impression,

the two can often feel the same from the developer's perspective ;)

btw, i'm quite impressed with cowboy. i think it is extremely nifty _and_ 
highly useful, two things one doesn't always get in one package ....

> On 06/18/2014 09:39 AM, Aaron J. Seigo wrote:
> > comparing with cowboy, the differences are glaring. for instance, in the
> > "getting started" guide for cowboy:
> > 
> > * we live in the microwave popcorn and
> > 10-minutes-is-a-long-video-on-youtube age. yet the first FOUR sections
> > are not about cowboy at all, but talking about the modern web and how to
> > learn erlang. as someone moderately familiar with the web, i don't care
> > about this. *just let me get started already!* if i'm reading the getting
> > started guide for cowboy, i probably don't need to be sold on either the
> > modern web OR erlang.
> 
> I'm not sure why you call it a "getting started guide" all over your
> email. It's the user guide.

a) Go to https://github.com/extend/cowboy
b) scroll down to "Getting Started"
c) first link: Read the Guide

you are (obviously) correct that it is the user guide. but it is presented to 
the (naive) first-time visitor as "Getting Started -> Guide" and it indeed 
starts with an Introduction part and has a "Getting Started" chapter.

in lieu of an "actual" getting started guide, the user guide *is* what i used 
to get started. ergo, it is the de facto getting started guide.

> It may have one "getting started" chapter,
> but its goal is not to get people started, but to be a complete guide.

understood :)

> This includes not only practical examples but also theory. Why theory?
..
> that. But some people do, and that's why we put these "obvious" things
> in the docs.

i'm not trying to tell you that what you've done is empirically wrong, but how 
non-optimal results may come from what is there right now in the way it is 
presented. whether you choose to pick anything useful from that is obviously 
up to you :)

specifically, i'd suggest that a more streamlined "getting started" guide that 
gets straight to the "your first cowboy server in one command" story would be 
valuable. it is something that the (quite nice) user guide does not provide, 
and which is something most people i know who are in the process of casually 
evaluating new frameworks are really helped by.
 
> > * being a good, modern developer with the attention span of the average
> > backyard squirrel i simply skipped straight to the "Getting Started"
> > section. the FIRST sentence is this:
> > 
> > "Setting up a working Erlang application is a little more complex than for
> > most other languages. The reason is that Erlang is designed to build
> > systems and not just simple applications."
> > 
> > ... aaaaaaaand cowboy just lost me as a user. i don't WANT complex[1], and
> > my application IS simple. so cowboy is not for me! right?
> 
> 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.

i completely understand. however, you don't need to confront the potential 
adopter with that rather scary proclamation as the *very first sentence*.

how do you *know* that everyone who reads that section will think "damn, THAT 
was super complicated!" honestly, that's not the impression i would have come 
away with myself ... but you *told* me it was complicated before i even got to 
decide.

show, don't tell. :)

now, as for "you can't just have one file" that's obvious true. but you *can* 
have a helper app that creates the file structure and basic files described in 
the (very clear!) step-by-step "getting started" section. i know because i 
have written and used exactly such tools many times in the past which generate 
significantly more complex boilerplate.

> 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 shows -> cowboy is very nice ...

> it'll never be as simple as nodejs. 

it doesn't have to be. "make everything as simple as possible, but no 
simpler," so said Einstein. dude was right. :) setting up a first "make me a 
toy demo app" with cowboy is not as simple as it could be. it does not need to 
be as simple as nodejs, but that particular step can be a lot simpler than it 
currently is.

> The next erlang.mk version will make it a little easier by generating a
> base project (using templates, as you say). But that will not change the

that will already be a very nice improvement! :)

> getting started chapter much, as we will still have to explain things.
> Instead of saying "create" it will say "edit", basically.

not really ... the getting started page can be condensed a LOT by skipping 
over details until the user has started the dummy app for the first time.

THEN it can start saying "now edit this file..." the reward (seeing a running 
cowboy app) is delayed; move that up a bit and then after that first hit of 
success start laying in the details.

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

that assumes there IS a "later on". if you lose me in the first page of 
documentation, then there will be no later on. to catch the squirrels out 
there, you need to convince them to stay so there is a "later on".

you can do that by giving me something that works immediately with as little 
effort, and explanation, as possible. if i can point my web browser to 
localhost:8080 after 30s and have a "hello, partner!" message appear i am 
much, much more likely to stick around for the explanations of how that just 
happened.

this is *exactly* what nodejs and other popular frameworks do. they are not as 
simple as they first look either. their little copy-n-paste toys are just a way 
to give the new comer a glimpse of possibility and give them a first success 
... all the learning lay ahead, and people are willing to put in that effort 
once they've decided it's "easy enough". people are funny that way :)

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

amen.

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

the first job is not to teach someone the right way.

the first job is to convince the person considering using the technology that 
they want to invest the time and effort to learn the right way.  more people 
will do that once they've agreed that it is within their reach.

one way to do that is to provide a quick and easy "win" with as few steps as 
possible. then once they've gotten to a first quick success, dirty and ignorant 
of the details, start them through the process of explaining how everything 
works and why.

> > oh, and bonus points if there is a file created just for route definitions
> > which would then be automatically included by the foo_app.erl to be
> > passed to cowboy_router:compile. having a "well known" place to define
> > routes will standardize cowboy using applications and allow the starting
> > dev to focus on what they care about (routes and handlers) while ignoring
> > the details like the app module. yes, yes, eventually they'll likely want
> > to dig into that as well, but not at the beginning. (this is an area that
> > cowboy+erlang could be even better than express+node.js)
> 
> 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.

i evidently skipped a step in my mental process here.. let me back up and try 
again ...

when i followed the cowboy user guide's "getting started" section, my first 
thought was "where should i put another route? should i just plonk it in 
hello_erlang_app:start/2, or is it cleaner to put it somewhere else ...?" 

that matters because every. single. question. a person evaluating a new 
technology has while getting started is a barrier. it signals to them that 
this is difficult and requires lots of decision making.

yet, if there was a nice little "routes.hrl" (or whatever) and the read was 
directed to add new routes there, it removes that question entirely.  i could 
get to adding a second route to play with the toy app and see if i actually do 
understand the idea of handlers without having to look into 
hello_erlange_app.erl at all.

streamline.

so i'm not suggesting cowboy should be a complete web framework, but that it 
should present what it already presents in a way that is more structured and 
therefore more approachable to the average new-comer. because that is who will 
be reading / using that part of the documentation :)

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

the difference is that the example does this:

Dispatch = cowboy_router:compile([
        %% {URIHost, list({URIPath, Handler, Opts})}
        {'_', [{'_', hello_handler, []}]}
    ])

ok, there's the hello_handler route.  awesome. now... if i want to add a 
second one, should i modify it in-place right there? should i create a list of 
routes elsewhere and pass that in, for readablity's sake? as a new comer, i 
wouldn't be ready to make those decisions and that means uncertainty because 
i'm being asked to make a decision i'm not ready to.

so answer it for them. given them a .hrl file with sth like:

routes = [
		{'_', [{'_', hello_handler, []}]}
	].

one could even provide a bunch of different sample routes with some in-line 
documentation describing what they do. it could be used in the very nicely 
written Routing section without having the "noise" of the rest of the 
hello_erlang_app.erl to step around.

yes, many (most) people really struggle with learning that much. for people 
who pick things up quickly, that seems very alien, but it's just how it is. 
there is no changing everyone else ;)

> > * i couldn't find the bragging section of the docs. ;) more seriously, the
> > getting started guide tries to sell me on the modern web and erlang's
> > place in it, but how about a fun little one-pager that backs up the
> > claims made in the main README: "Cowboy is a small, fast and modular HTTP
> > server written in Erlang." and " It is optimized for low latency and low
> > memory usage". show me the money^Hmeasurements! a simple set of charts
> > showing how many simultaneous connections can be handled and what kind of
> > latencies app the developers achieve on regular ol' hardware, along with
> > a LOC-you-need-to-write-for-a- barebones-app count would help convince
> > people and would be the thing that would get passed around on
> > stackoverflow, g+, twitter, etc. when justifying / recommending cowboy.
> 
> 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.

yes, i would believe you :)

> But still, how do you even brag about a difference that big with other
> platforms, and make people actually believe you?

numbers. in graphs.

no, seriously, it's just that simple. let me give you a fun example:

	http://hyperdex.org/performance/

(was sent that the other day by a "helpful" friend ...) there is really no 
useful context offered and very little way to validate the findings other than 
the links buried in the bottom "Discussion and Insights" footnote.

here's another (rather less suspect to me) example:

	http://haproxy.1wt.eu/10g.html

that is not a scientific result, in the sense that it does not provide a 
reproducable test, but it provides numbers from the developer (who is 
obviously invested and therefore biased) and people accept these numbers as 
guidelines for setting expectations.

and they link to these pages endlessly. and regurgitate them in their postings 
on reddit and stackoverflow. and, heaven forbid, slashdot ;)

in the case of the cowboy, i don't think you'd need to compare #s with other 
frameworks. simply show some numbers of real-world tests you (or your minions 
:) have done that demonstrate performance. just show the true capabilities of 
cowboy/erlang clearly as in the above two examples and people will accept it. 
they do so every day for other projects / products.

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

so benchmark what matters to you. people who care about those things will 
respond positively, and those who don't might start realizing that they ought 
to care about those things ;)

hell, write a paragraph about how you aren't benchmarking synthetic "hello 
world" performance because that only measures the benefit of having a JIT based 
system rather than the real world performance of a system (JIT or not) and 
include that on your page of numbers. :)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140618/ca5b0f89/attachment.bin>