[erlang-questions] node.js vs erlang

[Loïc Hoguin]

Okay I wanted to skip this thread entirely but you mentioned Cowboy and 
said weird things about it so I'll bite.

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

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.

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

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.

> * the rest of the "getting started" walks me through doing a ton of
> boilerplate stuff. it's nice to know how things work, but i'm a busy web dev
> (have i mentioned my lack of attention span yet? oh look, a peanut! and it's
> an event driven async peanut! yum! *runs off*). everything in that section
> ought to be boiled down to "run this one simple command and everything is done
> for you. click here to read about the gory details." and doing so should give
> me a fully functional application template that i can immediately start. that
> one command should probably take a simple config file with things like the app
> name and other variable details (such as which erlang apps to include in my
> awesome new project, including but also in addition to cowboy). basically, an
> npm-for-erlang.

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 
getting started chapter much, as we will still have to explain things. 
Instead of saying "create" it will say "edit", basically.

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.

But of course impatient people will prefer to waste their time by 
missing out on it.

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.

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

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

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

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.

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

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.

-- 
Loïc Hoguin
http://ninenines.eu