[erlang-questions] node.js vs erlang

[Joe Armstrong]

I'm trying to compare node.js with erlang. I'm a total node.js novice BTW - but I've written some JS.

Program 1 is just fibonacci - I want a web server to compute fib(N)

So requesting http://127.0.0.1:8124/fib?n=2 should compute and return fib(2)

My node.js attempt crashes

Here's the code in fib.js

--- fib.js

var http = require('http');

var url  = require('url');

function fib(n) {

  if (n < 2) {

    return 1;

  } else {

    return fib(n - 2) + fib(n - 1);

  }

}

http.createServer(function (req, res) {

    var q = url.parse(req.url, true).query;

    var n = q.n;

    var result = fib(n);

    console.log('fib('+ n + ')= '+result);

    res.writeHead(200, {'Content-Type': 'text/plain'});

    res.end(result.toString());

}).listen(8124, "127.0.0.1");

console.log('Server running at http://127.0.0.1:8124/');

-- end

-- now we run it

$ node fib.js

Server running at http://127.0.0.1:8124/

fib(2)= 2

/home/ejoearm/Dropbox/experiments/hello_world/fib.js:5

function fib(n) {

            ^

RangeError: Maximum call stack size exceeded

fib(2) has run out of stack space????

$ node --version

v0.8.21

Any ideas what I'm doing wrong

Cheers

/Joe

[Joacim G.]

I can't help with node.js but I found this informative:
http://notes.ericjiang.com/posts/751

/Jocke

> <http://127.0.0.1:8124/%27>);

>
> -- end
>
> -- now we run it
>
> $ node fib.js
> Server running at http://127.0.0.1:8124/
> fib(2)= 2
>
> /home/ejoearm/Dropbox/experiments/hello_world/fib.js:5
> function fib(n) {
> ^
> RangeError: Maximum call stack size exceeded
>
> fib(2) has run out of stack space????
>
> $ node --version
> v0.8.21
>
> Any ideas what I'm doing wrong
>
> Cheers
>
> /Joe
>
>
>
>
>
>
>
>

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Paulo F. Oliveira]

Hello, Joe.

If you include a console.log(req.url); inside your createServer callback you'll probably see that your browser is trying to obtain /favicon.ico (a second request), which causes the infinite loop, thus the RangeError, as n is undefined for the second call and you aren't dealing with this condition.

Hope it helps.

- Paulo F. Oliveira

[Juan Facorro]

Hi Joe,

There's a semicolon missing after the declaration of fib(), which for some reason, causes the stack overflow. After adding it the error went away.

HTH,

J

[Tom van Neerijnen]

I copy pasted your example and "$ curl http://127.0.0.1:8124/?n=2" =:= 2, so that works as expected.
However "$ curl http://127.0.0.1:8124/" resulted in the same crash as you got. Put a console.log(q); and maybe a console.log(n); in your http.createServer callback to make sure n is what you expect it to be. My guess is it's undefined or something that isn't a number, which your base case will never match and cause your call stack to overflow.

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--

Thomas van Neerijnen

http://tomvn.com

+4477 1709 7670

[Ivan Carmenates García]

Hi Joe,

 

I did try nodejs some time ago and I can tell from that experience that regards to development performance and confortable programming, nodejs is very nice, it is very intelligent way to program, it is faster too, but I have to tell you this, nodejs as a program language is very close or even more nicely than Erlang, but as a technology it is the biggest crap I ever taste, sorry about that, everything there explode and you have no control at all of the explodes, if the stack ran out; and it does quickly and easily, it just ran out without any possible solution and the system goes down inevitably, I came out to think that you cannot program a serious thing over that! Despite of that simple fact, all other is fine, nicely coding programming I think.

 

Best regards,

Ivan.

[Ulf Wiger]

On 16 Jun 2014, at 18:21, Ivan Carmenates García <co...@frcuba.co.cu> wrote:

I came out to think that you cannot program a serious thing over that! Despite of that simple fact, all other is fine, nicely coding programming I think.

Good one!  :)

BR,

Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.

http://feuerlabs.com

[Joe Armstrong]

On Tue, Jun 17, 2014 at 12:10 PM, Greg Young <gregor...@gmail.com> wrote:

Can you really compare the two? :) 

Yes - there are many things we can measure. Performance, Latency, memory usage and so on.

Right now I'm measuring latency - 

I set up a few thousand parallel processes which request fib(N) and measure the latency of the responses.

the results will be published when I understand them :-)

/Joe

 

--
Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting.
---
You received this message because you are subscribed to the Google Groups "Erlang Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programm...@googlegroups.com.
To post to this group, send email to erlang-pr...@googlegroups.com.
Visit this group at http://groups.google.com/group/erlang-programming.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[Greg Young]

Can you really compare the two? :) 

On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro <juan.f...@gmail.com> wrote:

--
Remember to send a copy to erlang (dot) questions (at) erlang (dot) org when posting.
---
You received this message because you are subscribed to the Google Groups "Erlang Programming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to erlang-programm...@googlegroups.com.
To post to this group, send email to erlang-pr...@googlegroups.com.
Visit this group at http://groups.google.com/group/erlang-programming.
For more options, visit https://groups.google.com/d/optout.

[Lee Sylvester]

As a heads up; I once built an app in NodeJS which did a lot of heavy lifting on connections and database calls.  I ran into some pretty major issues with file descriptors and resource usage which ended up being crippling with little room to manoeuvre.  I don’t get those issues, anymore, with Erlang :-)

Lee

[Greg Young]

Are you testing against single threaded node or one of the clustered versions or multiple processes or?

[Angel Java Lopez]

Ah!

Your browser, for some reason, is sending another request.

Add console.log(req.url) as first line in your function

In my chrome/windows/node 0.10.x the browser tries /favicon after http://127.0.0.1:8124/?n=3

Then, n is undefined

Then n < 2 is false

Then n - 2, n - 1 ARE NaN

Angel "Java" Lopez

@ajlopez

[Joe Armstrong]

On Tue, Jun 17, 2014 at 1:00 PM, Greg Young <gregor...@gmail.com> wrote:

Are you testing against single threaded node or one of the clustered versions or multiple processes or?

Single threaded

/Joe

[Darach Ennis]

Hi all,

For this to be comparable both Erlang and Node.js need to be running

similarly. I don't see how a concurrent Erlang runtime with multiple schedulers

can be compared with a single-threaded Node.js implementation objectively or

fairly...

Using node cluster with the same number of cluster instances as erlang

schedulers might be a fairer environment for comparison. However, as

numeric computations are fairly efficient in Node.js and inefficient in Erlang

relative to Java or C it may take a few iterations to get a fair comparison

in place. Node cluster is a standard part of node.js:

http://nodejs.org/api/cluster.html

There are various attempts at implementing fibers and lightweight threads

in Node.js (eg: https://github.com/laverdet/node-fibers/) but there is nothing

common here. This would approximate an erlang runtime more closely at

the cost of deviating a little from a commonly found node runtime... Ho hum.

As javascript runtimes start to adopt vectorized instructions and other

optimisations their speed relative to a C baseline has and will continue to

steadily improve and has been for a number of years, especially with V8.

Good luck with the benchmarking!

Cheers,

Darach.

[Joe Armstrong]

On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis <dar...@gmail.com> wrote:

Hi all,

For this to be comparable both Erlang and Node.js need to be running

similarly. I don't see how a concurrent Erlang runtime with multiple schedulers

can be compared with a single-threaded Node.js implementation objectively or

fairly...

It's actually the programming models I want to compare and not the

performance - what worries me about node is the run-to-completion

semantics of event callbacks - namely that a long-running event will block

the server preventing short computations from being performed. The

short jobs which could be done immediately have to wait until the long jobs

have finished - this should reflect in the average latencies of a request.

I made a little experiment (a fibonacci server in erlang and node) and fired off

1000 parallel requests to compute fib(N) with N a random number from 10..40.

As I suspected many of the fib(10) events are blocked by ongoing computation of

fib(40) - this reflect in the latencies.

Node is about 1.6 times faster than Erlang - but the latencies for small computations

are terrible - Erlang never blocks so the response times are more predictable.

And yes I know that fib can be offloaded to a background processor or parallelised

in JS with a bit of black magic - but manually converting a long lived computation into

a re-entrant non-blocking version is very difficult.

The node books say something like "make sure that callbacks run-to-completion quickly"

I would say that complying with this advice is extremely difficult. It's very difficult to guess

which computations will take a long time, and even if you know it's difficult to break them into

small re-entrant chunks.

Node is very popular so I'm trying to understand what it is about node that is attractive.

npm for example, looks well engineered and something we could learn from. The node

web servers are easy to setup and run, so I'd like to see if we could make equally 

easy to use Erlang servers.

Performance is not a primary concern - easy of programming and correctness are.

Cheers

/Joe

[Greg Young]

"The node books say something like "make sure that callbacks run-to-completion quickly"

I would say that complying with this advice is extremely difficult. It's very difficult to guess

which computations will take a long time, and even if you know it's difficult to break them into

small re-entrant chunks."

Remember what most people are working with in node. It is rare that building up a webpage has large amounts of CPU intensive work.

More so I'm actually quite surprised that with fib(40) vs fib(10) that these differences are measurable over a http test.

[Angel Java Lopez]

Just to add something. Normal and async fibonacci for node, from a book

https://github.com/ajlopez/NodeSamples/blob/master/MathWizard/math.js

There is a sample web server to test both

Angel "Java" Lopez

@ajlopez

[Paulo F. Oliveira]

"Node is very popular so I'm trying to understand what it is about node that is attractive."

Having recently moved from Node.js (JavaScript really) to Erlang, a few things come to mind:

1. a lot of browser frontend (i.e. JavaScript) developers almost don't have to learn anything new to develop server-side code using Node.js

2. npm (for sure) is one of the best package management systems I've used... really simple (oh, and the fact that you can use specific versions of deps in your app and not be restricted by a previous choice, sure helps a lot)

3. npmjs.org :D

4. the debugger (node-inspector): I miss this :(

5. you can share server-side and browser-side code

On the other hand, for high concurrency, I wouldn't recommend it (it's heavy when you have to spawn a few thousand processes to do _parallel_ and then the OS can't easily cope with this), as it's single threaded (ok, there's Cluster, but...). And also, the fact that tail recursion is non-existing...

At the moment, though, I enjoy prototyping with Node.js and implementing with Erlang. :)

- Paulo F. Oliveira

[John Kemp]

On 06/17/2014 08:41 AM, Joe Armstrong wrote:
>

[...]

> Performance is not a primary concern - easy of programming and
> correctness are.

I would note that it is possible to show that node is not as easy to
program as Erlang without measuring performance.

It is possible to do so by reading any node code that uses nested
callbacks (pretty much any example) vs. reading equivalent Erlang code.

In the node case, it is not easy to follow the flow of the code by
reading it (ie. in which order the callbacks will fire) leading to many
mistakes in programming which do not show up until a particular ordering
of activities occurs.

By contrast with Erlang, it is usually (in my experience) easy to follow
the flow of code by reading it. This leads to easier verification of
"correctness" too.

Just write a piece of non-blocking event-driven node code which
implements more than one callback function, where callbacks may be
nested. Then write the same code in Erlang. Which is easier to read? Is
it even possible to verify the correctness of the node code in all cases?

Regards,

- johnk

> <mailto:gregor...@gmail.com>> wrote:
>
> Can you really compare the two? :)
>
>
> Yes - there are many things we can measure. Performance,
> Latency, memory usage and so on.
>
> Right now I'm measuring latency -
>
> I set up a few thousand parallel processes which request
> fib(N) and measure the latency of the responses.
>
> the results will be published when I understand them :-)
>
> /Joe
>
>
>
>
>
>
> On Mon, Jun 16, 2014 at 5:55 PM, Juan Facorro
> <juan.f...@gmail.com

> /home/ejoearm/Dropbox/__experiments/hello_world/fib.__js:5

> function fib(n) {
> ^
> RangeError: Maximum call stack size exceeded
>
> fib(2) has run out of stack space????
>
> $ node --version
> v0.8.21
>
> Any ideas what I'm doing wrong
>
> Cheers
>
> /Joe
>
>
>
>
>
>
> --
> Remember to send a copy to erlang (dot)
> questions (at) erlang (dot) org when posting.
> ---
> You received this message because you are
> subscribed to the Google Groups "Erlang
> Programming" group.
> To unsubscribe from this group and stop
> receiving emails from it, send an email to
> erlang-programm...@googlegroups.com

> <mailto:erlang-programm...@googlegroups.com>.

> To post to this group, send email to
> erlang-pr...@googlegroups.com

> <mailto:erlang-pr...@googlegroups.com>.

> Visit this group at
> http://groups.google.com/group/erlang-programming.
> For more options, visit
> https://groups.google.com/d/optout.
>
>
>
>
> --
> Studying for the Turing test
>
>
>
>
>
> --
> Studying for the Turing test
>
>
>
> _______________________________________________
> erlang-questions mailing list

> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>
> http://erlang.org/mailman/listinfo/erlang-questions

[Jesper Louis Andersen]

On Tue, Jun 17, 2014 at 2:41 PM, Joe Armstrong <erl...@gmail.com> wrote:

It's actually the programming models I want to compare and not the

performance - what worries me about node is the run-to-completion

semantics of event callbacks - namely that a long-running event will block

the server preventing short computations from being performed. The

short jobs which could be done immediately have to wait until the long jobs

have finished - this should reflect in the average latencies of a request.

Shameless plug:

Have you by any chance read

http://jlouisramblings.blogspot.dk/2010/12/differences-between-nodejs-and-erlang_14.html

because I was down this road years ago. And I would like to hear if anything has happened. The graphical plots are gone, but the R summaries still hold and explain miserable variance for Node.js.

--
J.

[John Kemp]

On 06/17/2014 08:41 AM, Joe Armstrong wrote:

[...]

> Node is very popular so I'm trying to understand what it is about node
> that is attractive.

One of the reasons not yet mentioned for the popularity of node is the
"non-blocking, event-driven model" it uses.

But performance, ultimately, comes down to the underlying resources you
have (unit CPU, unit memory, network bandwidth between units) and how
they are allocated.

It's not that node gets this advantage "wrong". But in my experience,
any programming language can be used to exploit these underlying
resources appropriately, depending on how one arranges the resources,
and programs the whole system. This only changes when you consider
changes in the way underlying resources are configured (standard CPU vs
GPU vs FPGA for example)

Ruby vs. Java vs. node vs. Erlang vs. whatever makes no sense on that
level - they can all be used to make systems that work, depending on how
you use threads, processes and callbacks in a scalable manner, and how
much scale you need.

So in one sense, you should simply use your favourite language to do
whatever you want to do - as long as you understand how your system will
need to scale, and you are happy with whatever you will have to do to
make it scale for use, then all is good.

Certain things, however, make scaling simpler.

One of those things is having the ability to write a serial-looking
program, and yet having it easily form part of a parallel system. This
makes following the flow of control in a program much easier.

Another of those things is being able to "know" that your variable is
assigned only once and doesn't change after initial assignment.

I could mention other features of Erlang that make acquiring good-enough
performance much easier than it is with other languages.

In summary though, I believe that at a "whole-systems" level, node has
no particular performance advantage (assuming standard CPU architecture)
that would make me choose it over Ruby, Java or Erlang (all of which I
find easier to program, for different reasons).

I might choose node because the other developers on the project are node
specialists. But similarly, I would feel comfortable choosing whatever
other language made sense for reasons of team experience, or
readability, or some other non-performance reason.

Having used Erlang, it is difficult for me to use other languages,
because of the combination of elegance and large-systems functionality.
But I do it, knowing that teaching others how to program Erlang is not
my primary job responsibility, and that appropriately-scalable systems
can be built in most common languages, as long as you understand how to
make a reasonable rough cut at the first version of the system and what
to do with the measurements you should make afterwards :)

So, I think that what makes node attractive is pretty much a fallacy, or
rather, that this claimed advantage of node (non-blocking, event-driven
IO) has significant disadvantages over other languages, when thinking at
a whole-systems level.

Regards,

- johnk

[Ngoc Dao]

> 4. the debugger (node-inspector): I miss this :(

Thanks for the info. I didn't know this tool!

But in Erlang, you have nearly similar tool "debugger":

http://vimeo.com/32724400

[Jesper Louis Andersen]

On Tue, Jun 17, 2014 at 3:58 PM, John Kemp <jo...@jkemp.net> wrote:

In summary though, I believe that at a "whole-systems" level, node has no particular performance advantage (assuming standard CPU architecture) that would make me choose it over Ruby, Java or Erlang (all of which I find easier to program, for different reasons).

In fact, if the Node.js model is so good, I'd go with OCaml+Core.Async any day. Async defines enough tooling through operators that I can get a monad in which my writing style can be direct while having all the advantages of a "non-blocking" system.

But the existence of languages like Erlang and Go, the realization Haskell/GHC contains lots of tooling for doing concurrent work kind of tells a story that this might not be enough.

And the existence of Mozart/Oz and Erlang also tells a different equally important story about distribution.

--
J.

[zxq9]

On Tuesday 17 June 2014 14:41:28 Joe Armstrong wrote:
> ... but manually converting a long lived computation into

> a re-entrant non-blocking version is very difficult.
>
> The node books say something like "make sure that callbacks
> run-to-completion quickly"
> I would say that complying with this advice is extremely difficult. It's
> very difficult to guess
> which computations will take a long time, and even if you know it's
> difficult to break them into
> small re-entrant chunks.

This.

You can't hit the nail any more precisely on the head.

> Node is very popular so I'm trying to understand what it is about node that
> is attractive.
> npm for example, looks well engineered and something we could learn from.
> The node
> web servers are easy to setup and run, so I'd like to see if we could make
> equally
> easy to use Erlang servers.

"Easy" is not the same thing as "simple". A lot of people are familiar with JS
and node.js is a fad that speaks to the web 2.0 crowd that can't/won't digest
a serious discussion about the issues you are raising above. *Anything* in JS
is going to be easier for this legion of web folks compared to, well, anything
that isn't JS.

You are trying to apply your deep technical expertise to a shallow social
phenomenon. As Alan Kay somewhat recently observed, computer science has
become pop-culture and has very little to do with engineering. I'd go further
and say he was really talking about the software development landscape as
applies to the web and other low-performance applications. Folks like you are
coming from a different world than the folks that use and (especially) have
made node.js a pop phenomenon.

So, don't worry about what is popular. (Popularity is no indication of value
-- I don't think this point needs further support.) If you do that at the
language/platform/infrastructure level you will merely re-discover that
Richard Gabriel was correct, marketing trumps engineering, the Huns will
always crush an overly domesticated Rome, and worse is indeed better. IOW,
you'll turn Erlang and its platform into Java and its vm.

That would make me sad -- for so many reasons.

-CRE

PS: The corrolary to the above is that if the goal is popularity, then neither
the means nor the path to success can be inherently technical in nature.

[john pradeep]

That's a good point Darach. Just to add to to that, it would be even nice if the bench marking is performed for 2 cases: CPU intensive & IO intensive code.

Would love to see Joe's comparison!

Cheers!

[Pedro Narciso García Revington]

Hey Joe

Node is very popular so I'm trying to understand what it is about node that is attractive.

Lots of people already know js, so it seems an easy platform to get in.

What I love about node:

• npm 
  
• modules ecosystem 
  
• easy to deploy 
  
• easy to start: you can use js, you do not need a specific ide, easy to install, good documentation, and examples
  
• tjhollowaychuck: 
  this guy have made lots of projects that makes your life easier: express, mocha, jade, supertest, commander.
  Lots of examples, simplicity, elegant design and good documentation
  https://github.com/visionmedia
• You can develop applications very fast due to javascripts nature (dynamic typing, closures, easy introspection, prototype inheritance)
  
  

[Raoul Duke]

yes and no. there are things to learn *from* node, but they probably
aren't *node* itself, they are the ecosystem. :-)

[Raoul Duke]

p.s. others have pointed out / complained about node.js of course!
we're not alone!

http://ncannasse.fr/blog/is_nodejs_wrong

[Thomas Lindgren]

A couple of years ago, I had a BSc student implement a simple but realistic web service (realistic enough to be a replacement for one we were using in production), in Ruby, Node and Erlang. Ruby was slowest, as expected. Overall, Erlang beat Node. In particular, while they were roughly the same "best" performance, Node had a much greater variation in response latency.

Best,

Thomas

On Tuesday, June 17, 2014 10:06 PM, Thomas Lindgren <thomasl...@yahoo.com> wrote:

[Miles Fidelman]

Folks,

Let's not forget what node.js is, and it's intent: It's an
implementation of server-side javascript, pure and simple.

Personally, I liked Jaxer (before it died) better. Where node.js is
framed more as a general purpose environment, Jaxer was framed more as
"let's push some the browser to the server" - which was just perfect for
things like database access, comms access, etc. Essentially it was
'write a web page/app with javascript, then designate some of it for
server-side execution.'

And Aptana did a nice job of an IDE for both client- and server- side code.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Mark Nijhof]

I just found this: http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ which I think is an interesting comparison

And here is an interesting thread as well: http://programmers.stackexchange.com/questions/85975/learning-erlang-vs-learning-node-js

-Mark

--

Mark Nijhof

t:   @MarkNijhof
s:  marknijhof

[Pedro Narciso García Revington]

Hey Mark, 

That benchmark is a little bit outdated. Have a look at this one http://www.techempower.com/benchmarks

[Mark Nijhof]

Thanks, seen it before but forgot about it

[zxq9]

On Tuesday 17 June 2014 16:53:14 Miles Fidelman wrote:
> Folks,
>
> Let's not forget what node.js is, and it's intent: It's an
> implementation of server-side javascript, pure and simple.
>
> Personally, I liked Jaxer (before it died) better. Where node.js is
> framed more as a general purpose environment, Jaxer was framed more as
> "let's push some the browser to the server" - which was just perfect for
> things like database access, comms access, etc. Essentially it was
> 'write a web page/app with javascript, then designate some of it for
> server-side execution.'
>
> And Aptana did a nice job of an IDE for both client- and server- side code.

It is unclear whether considering intent and role with regard to the web is
useful. An argument can be made that most elements related to the web today
have already forgotten their roles and intent -- the point of dark comedy.

[Raoul Duke]

> Let's not forget what node.js is, and it's intent: It's an implementation
> of server-side javascript, pure and simple.

hrm, i do not believe that statement is correct. something like Rhino
would more fit that statement, i think. or even just V8. node = V8 +
more stuff, so i think that sorta disproves what you wrote?

[Miles Fidelman]

Raoul Duke wrote:
>> Let's not forget what node.js is, and it's intent: It's an implementation
>> of server-side javascript, pure and simple.
> hrm, i do not believe that statement is correct. something like Rhino
> would more fit that statement, i think. or even just V8. node = V8 +
> more stuff, so i think that sorta disproves what you wrote?
> _______________________________________________
>

Not quite. V8 is a javascript engine, as is Rhino, as is SpiderMonkey,
as is WebKit, etc. In particular, V8 is the javascript engine for the
Chrome browser. node wraps glue around it to create a server-side
environment.

A couple of references from http://nodejs.org/about/ - both 'intro to
node.js' type slide decks from Ryan Dahl - who is kind of the ultimate
authority, in that he's the author of node:

Slide 2 (right after the cover) of http://nodejs.org/jsconf2010.pdf
starts with this statement: "node.js: Evented Server-side Javascript"

A slightly earlier version
(http://s3.amazonaws.com/four.livejournal/20091117/jsconf.pdf) says this
(again, slide 2):

node.js
in brief:
Server-side Javascript
Built on Google’s V8
Evented, non-blocking I/O. Similar to
EventMachine or Twisted.
CommonJS module system.
8000 lines of C/C++, 2000 lines of
Javascript, 14 contributors.

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

_______________________________________________

[Ivan Carmenates García]

Hi all, Joe,

I think the understanding of how node became so popular, is because the one who invented node, he had one goal in mind, to take the advantage of the already well formed and big javascript community, javascript became so popular it had its reasons, but it was just a client-side technology!, so what about a server side technology that complements that already fully operational client-side tec? Using the same community? noting to create, noting to grow, only putting in the eyes of the fools another foolish. That's what nodejs is.

Now imagine the turn of programming technics if all browser companies could include interpretation for Erlang natively? And you could communicate two Erlang's nodes one in the client (browser) another in the server as the same way as Erlang always do, Even so without having that big community, I'm sure the entire web community will be forced to see that new tec that is in all browsers and have the same counterpart in the server

Best,
Ivan.

-----Mensaje original-----
De: erlang-quest...@erlang.org [mailto:erlang-quest...@erlang.org] En nombre de Miles Fidelman
Enviado el: martes, 17 de junio de 2014 10:26 p.m.
Para: Erlang
Asunto: Re: [erlang-questions] node.js vs erlang

[Ivan Carmenates García]

Hi all,

 

Paulo F. Oliveira says: “…At the moment, though, I enjoy prototyping with Node.js and implementing with Erlang. :)…”

 

Yes Paulo, I definely think that it is what nodejs is about, it is very nice to prototyping things because of the code, easily to understand and program; a different way of thinking (no so nice like Erlang but.. still..), but noting seriously such as what you can do with Erlang you can build with nodejs I think.

 

Best,

Ivan.

 

 

 

 

De: erlang-quest...@erlang.org [mailto:erlang-quest...@erlang.org] En nombre de Paulo F. Oliveira
Enviado el: martes, 17 de junio de 2014 09:07 a.m.
Para: Joe Armstrong
CC: Greg Young; Juan Facorro; Erlang; erlang-pr...@googlegroups.com
Asunto: Re: [erlang-questions] node.js vs erlang

 

"Node is very popular so I'm trying to understand what it is about node that is attractive."

[Aaron J. Seigo]

(apologies for the length of this email .. i've been poking at it for a couple
days since Joe's first email and finally combined the ramblings into something
resembling a reply. it's a set of ponderings / reflections of someone new to
erlang who has written non-trivial apps with node.js ... which seems to be
pretty much exactly where Joe is trying to explore :)

On Tuesday, June 17, 2014 14:41:28 Joe Armstrong wrote:
> The node books say something like "make sure that callbacks
> run-to-completion quickly"
> I would say that complying with this advice is extremely difficult. It's
> very difficult to guess
> which computations will take a long time, and even if you know it's
> difficult to break them into
> small re-entrant chunks.

... which is generally why CPU-bound tasks are to be avoided in the
node.js world. conventional wisdom (be that as it may) is that node is
appropriate for I/O bound processes which operate on streams. anything else
and one ends spawning processes and waiting for response (which makes it async
in the node.js runtime again, but that is not particularly lightweight ...)

as such, your choice of benchmarks (fib) is not really going to produce
representative benchmarks of node.js as used in the wild. (by sane people
anyways :)

an i/o bound process is going to show a more typical node.js performance
profile e.g.:

* call into a database (sql or key/value, whatever) and retrieve N rows from a
large dataset based on the client query (i.e. an offset and limit), do some
light post-processing of the retrieved data (if any) and return the results as
a json response (typical of the ajax-y style apps node.js is often pressed
into...)

* stream a file back to a client on request, reading from the local file and
writing to the socket both happening in chunked async requests (made easy with
the built-in file module)

in those workloads, or so the theory goes, much of the wall clock time is
spent waiting for response from the data source (i.e. the database in the
above example) and related i/o to the client. using that time to run other
application code is a good way to handle concurrent requests at greater volume
/ lower latency. and it does work reasonably well, if not presenting an
optimal solution. (nothing in that paragraph is rocket science, of course :)

(p.s. benchmarking is hard, so props for taking a run at this ..)

> Node is very popular so I'm trying to understand what it is about node that
> is attractive.
> npm for example, looks well engineered and something we could learn from.

for many node.js projects, including ones i've worked on, this has been a HUGE
part of the reason to go with it. the monstrous number of easily integrated
3rd party modules is a significant asset, and helps make up for many of the
annoyances.

the path to node.js seems to go something like:

* developer hears the hype about node.js (scalable, easy, ..)
* figuring how they already "know" javascript, developer dips a toe in the
node.js water and finds that it is easy to do simple things (e.g. a toy project
to learn the framework with)
* developer discovers npm and is hooked ("I don't have to write most of my app
myself!")

that progression from "hear the hype" through to finding the killer feature of
node (npm and the wide world of node.js modules) is quick and rewarding (via
instant success).

perhaps that is sth that erlang can learn from :)

> The node
> web servers are easy to setup and run, so I'd like to see if we could make

express is indeed pretty damn fine, but some of the other modules such as
async[1][2] are hugely critical by encapsulating a lot of the typical patterns
that would otherwise be repetitive drudgework (mostly due to the async nature
of node.js). without these sorts of modules, using node.js would be a lot less
attractive (which is why they got written, obviously -> itch scratched!).

so when looking at what makes it easy to get started, the web server modules
(e.g. express) are only part of the story.

(and of course, being able to easily share and include modules is a key part
of why those modules exist in the first place ...)

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.

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

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

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)

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

[1] really, i personally don't care; but i'm channeling the spirit of the
average web dev here :)

> Performance is not a primary concern - easy of programming and correctness
> are.

this is a fundamental weakness with node.js imho. it is definitely easy to get
*started* with a node.js based project, but keeping it sane takes discipline.
which means most applications likely become horrible little monsters given
enough time. i am convinced that it is unpossible (similar to, but not the
same, as impossible ;) to write and maintain a large, reliable node.js
application without *extensive* unit tests which are run continuously during
development (not just integration).

as the order of blocks in the source code does not correlate with the actual
execution order, and that execution order will vary at runtime due to
fluctuations in the surrounding aether (read: database and network latency), it
is very difficult to write code that can be easily debugged simply by reading it
or naively instrumenting it with debug statements. (yes, this is not how to
maintain a code base, but it's how many devs actually work.)

the answer is LOTS of unit tests, including for cases one normally wouldn't
test for in other languages / frameworks (unless being paid by the test unit
;). it was also uncomfortably common (i.e. more times than zero) to see
tests fail due to the peculiarities of node.js messing with the test
framework, resulting in false negatives that often take a fair amount of time
to identify and then instrument around. yep: a testing run may not behave
sufficiently similar to the production run, which kind of erodes the value of
having tests ....

thankfully node has lovely tools like mocha and istanbul to drive unit
tests and generate coverage reports relatively quickly, making the may-as-
well-be-enforced TDD manageable.

combine this with a language that requires defensive programming (resulting in
more paths to test, obviously) and the ugliness becomes evident. even though
it is a scripted environment, getting a node.js app to spew errors everywhere
or even crash outright is far too easy without extensive defensive
programming.

so it is pretty much expected that your node.js app will at some point fall
over and die. which is why there are tools like forever and node modules
offering integration with systemd so provide supervision. only if node.js had
such concepts built in, how wonderful would that be? wish i knew of such a
language ;)

if erlang can learn something from node it might be the value of loudly,
clearly and enthusiastically telling the world what it is REALLY DAMN GOOD at.
people will forgive warts and annoyances if they understand the thing they
*want* about a given framework.

people think 25k connections on a multi-core system is mindblowing; that
multi-process / threading *must* be hard (enough to avoid if you can,
anyways); that one simple frameworks are going to be good at i/o or cpu bound
tasks, but rarely both (to get both you get to use a complex
language+framework) ... erlang addresses exactly those issues, and as such has
an amazing story for the needs of modern network services (among other use
cases). there are some truly amazing things written in erlang (something that
i don't think enough people are aware of, btw) that would help in emphasizing
that story ....

i had erlang on my "list of things to investigate" for a while, and when i
finally got around to it i found it to be a minor revelation in terms of design
and capabilities. not perfect, but closer to perfect than most of the
alternatives i've used. i really should not have had to investigate to find
that out, though: i ought to have been driven to erlang because that set of
revelations was widely distributed in easy-to-digest form (and without a bunch
of warnings about how string manip sucks, or how erlang runtimes are complex
to set up, or ...)

[1] https://github.com/caolan/async
[2] http://www.sebastianseilund.com/nodejs-async-in-practice

--
Aaron J. Seigo

[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

[Gokhan Boranalp]

--
BR,
\|/ Kunthar

[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

[Ulf Wiger]

On 18 Jun 2014, at 07:49, Ivan Carmenates García <co...@frcuba.co.cu> wrote:

Yes Paulo, I definely think that it is what nodejs is about, it is very nice to prototyping things because of the code, easily to understand and program; a different way of thinking (no so nice like Erlang but.. still..), but noting seriously such as what you can do with Erlang you can build with nodejs I think.

An interesting exercise might be to map https://github.com/uwiger/pots,

specifically the lim_asynch.erl API, to e.g. websockets, and try to program

the POTS subscriber loop in node.js.

The challenges of the exercise are outlined in this presentation:

http://www.infoq.com/presentations/Death-by-Accidental-Complexity

I know that there are techniques developed in node.js to deal with the

sort of issues that arise. The problem is illustrating to people when they

are needed, and just how bad it can get without them.

BR,

Ulf W

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.

http://feuerlabs.com

[Loïc Hoguin]

On 06/18/2014 12:10 PM, Aaron J. Seigo wrote:
> 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.

That's stretching it. All the documentation and examples are in that
section of the readme. It's not particularly ordered either, some people
prefer starting with examples, others a reference, yet others a guide.
And in those people will need one or another element of information.

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

I don't really care about people who casually evaluate things. Why would
I? I never did, and that never stopped Cowboy from getting new users.

I care about my current users. All the work I do is for the sake of
current users. Even the theory stuff was added at the demand of current,
albeit beginner, users. All the work I do now is entirely based on
feedback I receive.

I'm not sure why people would use the getting started chapter to
casually evaluate Cowboy though. There are a dozen or more prebuilt
examples that can be ran with a single command. They range from hello
world to Websocket to REST services. The getting started isn't there to
replace them, it's there to get people who have decided to use Cowboy,
well, started.

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

Maybe not. But it's easier to send a patch than tell completely
unrelated people it's wrong to do that in a completely unrelated topic.

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

We'll still have to describe it though, so it makes little difference to
the text, as I said before. It'll just save a couple keystrokes to the
user. Which is obviously good, but not to die for.

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

Then you should explain how. Send a patch showing how you think it
should be done, for example. At least we'll know exactly what can be
improved.

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

But you need to edit the file to get it working. I'm not sure what
you're getting at there.

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

That's what the examples are for. You can even copy paste an example and
add your things directly if that's what you want. Many people start this
way. But it doesn't fit everyone's way of learning things.

You're taking a small part of the documentation like it's the only thing
Cowboy has. It's not. Different people use different things to
experiment or get started. I think we cover a pretty large part of the
population with what Cowboy offers.

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

But teaching them the wrong way is more immediate work for them. And
completely unrelated to actually learning Cowboy. I'm not sure what
you're getting at there.

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

That's actually what the getting started is. It doesn't actually explain
anything. It is just a step by step to making a Cowboy based
application. I'm not sure where you see details in there.

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

It tells you where to put them. At no point will you see the
documentation, examples or even me saying to put the routes anywhere
else. I'm not sure what made you want to put them in a different file,
perhaps habit from using other things.

The only thing I would ever do different compared to that is to make a
function in that same module returning the routes, but then only if I'll
ever need to update them live. And that'd be a very advanced subject
that is not covered in the guide at this point.

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

I'm not sure how going from "everything is functions" to "everything is
functions except these things that are configuration files" is going to
help anyone. Keep it simple.

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

Perhaps, but then it's the first such feedback I get. And I have both
smart and dumb users. (No offense! I'm definitely in the dumb category
myself.)

It sounds more and more that it's just unusual for you that there's no
configuration file and it's all done using functions. Well that's not
going to change anytime soon because that's kind of the point.

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

I could. But it takes a lot of time. And other things take precedence,
like finishing the guide and such. If anyone wants to put numbers out
for Erlang and Cowboy though, be my guest.

It's not obvious anyone would care anyway. Whatsapp published a few
times their peaks, having almost 3 million concurrent connections on one
server using Erlang, and we didn't really see an influx of new Erlang
users because of that. Most people don't play in that category.

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

I don't really benchmark anymore. I just do when I want to make sure a
change didn't kill performance. Benchmarks don't matter much to me.
There's more important things to take care of before I go back to
benchmarking.

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

I'm not sure how to write a benchmark that does not give an unfair
advantage to a JIT based system. I'm not even sure how to write a good
benchmark. They're a nice tool to have a general idea that what you did
isn't worse than what you had before, but that's all they are.

[Ciprian Dorin Craciun]

On Tue, Jun 17, 2014 at 3:41 PM, Joe Armstrong <erl...@gmail.com> wrote:
> It's actually the programming models I want to compare and not the
> performance - what worries me about node is the run-to-completion
> semantics of event callbacks - namely that a long-running event will block
> the server preventing short computations from being performed. The
> short jobs which could be done immediately have to wait until the long jobs
> have finished - this should reflect in the average latencies of a request.
>
> I made a little experiment (a fibonacci server in erlang and node) and fired
> off
> 1000 parallel requests to compute fib(N) with N a random number from 10..40.
>
> As I suspected many of the fib(10) events are blocked by ongoing computation
> of
> fib(40) - this reflect in the latencies.

I'm not if someone suggested this before, you Joe hinted at it,
but if you need to do a lengthy computational job in pure NodeJS (thus
no background threads / processes / other magic), you could use the
`process.nextTick` and manually implement "reductions" like the BEAM
interpreter does.

http://nodejs.org/api/process.html#process_process_nexttick_callback


For example (completely untested code, and probably with "off-by-one bugs"):

~~~~
var fibReductions = 10;

function fib (n, onCompletion) {
fibRec (2, 1, 1, n, fibReductions, onCompletion);
}

function fibRec (i, s1, s2, n, reductions, onCompletion) {

if (i >= n) {
// see notes below why we use `process.nextTick` even here!
process.nextTick (function () { onCompletion (s2); });
return;
}

if (reductions > 0)
fibRec (i + 1, s2, s1 + s2, n, reductions - 1, onCompletion);
else
process.nextTick (function () {
fibRec (i + 1, s2, s1 + s2, n, fibReductions, onCompletion);
});
}
~~~~


Indeed I cheated by applying the tail-recursive technique to my
function, which eases the implementation of the reduction technique,
else my code would have been more convoluted than this.

But I hope this proves the point that if needed NodeJS could be
used even in these cases.

Ciprian.


P.S.: I chose to always call `process.nextTick (function () {
callback (outcome); })` even if the result is immediate, because me as
a developer expect that a callback is always called after I exit from
my function, like in the example below:

~~~~
function doSomeStuff () {

var someClosure = {};

initiateAction (function (outcome) {
doSomethingElse (someClosure.expectedValue, outcome);
});

someClosure.expectedValue = ...;

...
}
~~~~

[Raoul Duke]

[how did this thread get onto multiple erlang lists? :-]

> But I hope this proves the point that if needed NodeJS could be
> used even in these cases.

personally, i hope this proves the point that nodejs sucks. ;-)

[Kenneth Lundin]

On Wed, Jun 18, 2014 at 11:02 AM, Loïc Hoguin <es...@ninenines.eu> wrote:

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

 

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

If this is written in the Cowboy User Guide I think it is a bit unfortunate. I don't agree that it need to be more complex to set up a working

Erlang application than it is in many other languages. Maybe it is true in the way you have choosen but for sure there are more simplistic ways also. And in other languages it is also more complicated if you need a serious server with logging, possibility to upgrade etc.

I can come up with many non complex approaches. Whats wrong with erl -run ..... and having the module(s) in the current path?

I mean that if you have a more complex set up with Erlang maybe you also get features that you don't get with a simple setup in another language?

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.

That is what I meant, you are using a more complex setup with Erlang in order to get more features. So the comparision with other languages "simple setup" is not fair.

Cut, cut .....

But also note that I think it is important to make it easier for beginners to approach Erlang.  We are working on that and

are happy to cooperate with the Erlang community on this.

--

Loïc Hoguin
http://ninenines.eu

Kenneth, Erlang/OTP, Ericsson

[Loïc Hoguin]

On 06/18/2014 10:22 PM, Kenneth Lundin wrote:
> That is what I meant, you are using a more complex setup with Erlang in
> order to get more features. So the comparision with other languages
> "simple setup" is not fair.

The setup is more complex but the way we get there isn't. Have you read
the getting started chapter[1]? The release part is smaller than it
would take to explain "erl -run" or "erl -s": we don't have to write
extra code for it, we don't have to manually setup paths, we don't have
to deal with reltool, and so on. It's literally "create relx.config, put
this in it, run make again". Bam you got a release. That part can't get
any simpler.

Erlang *is* more complex to use than many other languages (it is still
simpler than C, C++ and the like though). Either you do things manually
by downloading dependencies manually and such, or you use a build system
like erlang.mk (or rebar) to automate things which requires you to
create an OTP application.

Because erlang.mk automates the use of relx to build releases it is
actually simpler to make a release than manually setup paths and
whatnot. We just have to create the one file! We don't deal with reltool
here, creating the release is *really* easier than not.

There's no simpler alternative to all that in the Erlang ecosystem. We
will be able to make it a little simpler by having templates instead of
making the user copy things, but the getting started chapter will not go
down in length dramatically because of this.

We could remove all explanations to make it perhaps half the size it
currently is, but then we removed all explanations. It's a chapter about
getting started, it's supposed to provide initial pointers to users, not
just get them to run an example and then ask themselves "now what?". We
have actual examples for people that want that already.

I am not even sure what triggers all these good comments about the
nodejs documentation. Sure it has a 6 lines and 1 command example on its
front page. There's no denying that. Then what? A link to API docs. I
have *no* idea how people manage to learn how to use it. Surely by using
other resources than these, because while I'm confident I could run the
front page example quickly, I am also confident that's about all I could
do with it for a rather long time until I manage to figure out how to do
anything meaningful, if I were to only use the official docs.

[1] http://ninenines.eu/docs/en/cowboy/HEAD/guide/getting_started/

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

[Aaron J. Seigo]

On Thursday, June 19, 2014 01:30:02 Loïc Hoguin wrote:
> I am not even sure what triggers all these good comments about the
> nodejs documentation. Sure it has a 6 lines and 1 command example on its
> front page. There's no denying that. Then what? A link to API docs. I
> have *no* idea how people manage to learn how to use it. Surely by using

that's exactly the (non-intuitive) lesson to take away: you can have poor
documentation and expect people to do lots of self-training and research BUT
if you do these three "simple" things you can still be successful at spreading
your tech:

0. attract: tell everyone what your product is really good at in a very
simple, positive manner[1]

1. be positive: greet potential adopters with positivity[1] and they will
reflect that back

2. have a "quick hook": give people something super quick and super easy to do
at the very start. this gives them the feeling of accomplishment, even if it
is completely trivial[3]. having tasted success (trivial as it may be) they
will invest time/energy to get more.

by doing those 3 things, nodejs can have a steep learning curve and still
succeed in getting lots of users.

conversely, you can have awesome documentation, but if you don't attract and
quickly hook potential adopters, fewer people will adopt the technology.

personally, i think cowboy's docs are pretty damn good. but i can see how some
potential adopters are being lost. if the three things above were implemented,
without changing anything substantial in the documentation, more people might
end up using cowboy / erlang. which would always be nice :)

tell you what: i've been looking for an area of erlang docs to contribute to,
perhaps this is a good place to start. i'll try my hand at implementing the
above 3-point-strategy in cowboy's docs and submit a pull request when i'm
done ... always better to do than to the tell, right? :) i'll try and block
some time for this in the next few days ....

[1] that usually means it isn't 100% complete and accurate due to summarizing
and glossing over details to keep it simple; the performance benchmarks i
referenced in a previous email are good examples of this
[2] the opening statement on the node.js website, and the first page of their
documentations, are only about positives. they don't warn people about how
tricky dynamic, async code that gets called non-sequentially can be , for
instance.
[3] for nodejs, that is "An Example: A Webserver" bit on their homepage

--
Aaron J. Seigo

[Loïc Hoguin]

On 06/19/2014 08:50 AM, Aaron J. Seigo wrote:
> by doing those 3 things, nodejs can have a steep learning curve and still
> succeed in getting lots of users.

That's another thing I don't understand. People always say nodejs has
lots of users. Yet I haven't heard of a single success story.

Erlang, you don't have to look far. Most big companies use Erlang. Half
the world's phone communications go through Erlang. You can find Erlang
in space. Heck even npm, the nodejs package manager, uses Erlang.

So my question then is: on what is the hype built? It certainly doesn't
seem to be built on the capabilities of the platform. I doubt it's
because it has one short example on its front page either. It probably
*helps* but it's not *why* there's hype about it.

If you want to attract hypey people you have to build hype around
Erlang, and that's much harder because you can't just hop in, everything
is different and you have to restart learning from scratch. As simple as
an example you might put on its front page, it will not get the point
across as well as one for a familiar language.

[Ivan Uemlianin]

Afaics nodejs is aimed squarely at people who (a) only know javascript,
and (b) don't want to learn any other programming languages. For this
market segment, I can certainly imagine nodejs is very exciting.

On 19/06/2014 09:52, Loïc Hoguin wrote:
> On 06/19/2014 08:50 AM, Aaron J. Seigo wrote:
>> by doing those 3 things, nodejs can have a steep learning curve and still
>> succeed in getting lots of users.
>
> That's another thing I don't understand. People always say nodejs has
> lots of users. Yet I haven't heard of a single success story.
>
> Erlang, you don't have to look far. Most big companies use Erlang. Half
> the world's phone communications go through Erlang. You can find Erlang
> in space. Heck even npm, the nodejs package manager, uses Erlang.
>
> So my question then is: on what is the hype built? It certainly doesn't
> seem to be built on the capabilities of the platform. I doubt it's
> because it has one short example on its front page either. It probably
> *helps* but it's not *why* there's hype about it.
>
> If you want to attract hypey people you have to build hype around
> Erlang, and that's much harder because you can't just hop in, everything
> is different and you have to restart learning from scratch. As simple as
> an example you might put on its front page, it will not get the point
> across as well as one for a familiar language.
>

--
============================================================
Ivan A. Uemlianin PhD
Llaisdy
Speech Technology Research and Development

iv...@llaisdy.com
www.llaisdy.com
llaisdy.wordpress.com
github.com/llaisdy
www.linkedin.com/in/ivanuemlianin

festina lente
============================================================

[Karl Nilsson]

I followed the cowboy getting started tutorial and found it very reassuring to be taken all the way to generating a release. I am pretty sure I could build on that sample and actually create something that could be used. I think there is a lot of value in that. Personally I find tweet sized getting started examples very unsatisfactory and prefer something that gives and indication of workflow as well as the language. Hipsters may feel differently.

Karl

--
Karl Nilsson

twitter: @kjnilsson

blog: coderkarl.wordpress.com

[John Kemp]

On 06/19/2014 05:07 AM, Ivan Uemlianin wrote:
> Afaics nodejs is aimed squarely at people who (a) only know javascript,

What is wrong with that? Cowboy is aimed at people who know Erlang.
Rails is aimed at people who know Ruby.

Personally, I program in several languages, including Javascript. I
found node easy to write because of my Javascript experience, mostly
because of how callbacks are used. But I don't "only know Javascript".

> and (b) don't want to learn any other programming languages. For this
> market segment, I can certainly imagine nodejs is very exciting.

Eh?

I try to regularly evaluate new languages and platforms to use, and I
doubt I'm the only person who does that.

Node was exciting (to me) because it promised a nice solution to the
I/O-bound scenarios which (I think) Aaron described in pretty good
detail. "Event-driven, non-blocking I/O, server-side Javascript". Node
delivers on those fronts, just like it says it does. It doesn't matter
that there are better things out there (for some definition of better).
Yes, there is hype around node. And yes, it has problems too. But the
platform does have benefits.

Disparaging the platform or the people who use it seems less than
helpful. Helping aid in the understanding of how Erlang compares to node
may be more helpful.

- johnk

>
> On 19/06/2014 09:52, Loïc Hoguin wrote:
>> On 06/19/2014 08:50 AM, Aaron J. Seigo wrote:
>>> by doing those 3 things, nodejs can have a steep learning curve and
>>> still
>>> succeed in getting lots of users.
>>
>> That's another thing I don't understand. People always say nodejs has
>> lots of users. Yet I haven't heard of a single success story.
>>
>> Erlang, you don't have to look far. Most big companies use Erlang. Half
>> the world's phone communications go through Erlang. You can find Erlang
>> in space. Heck even npm, the nodejs package manager, uses Erlang.
>>
>> So my question then is: on what is the hype built? It certainly doesn't
>> seem to be built on the capabilities of the platform. I doubt it's
>> because it has one short example on its front page either. It probably
>> *helps* but it's not *why* there's hype about it.
>>
>> If you want to attract hypey people you have to build hype around
>> Erlang, and that's much harder because you can't just hop in, everything
>> is different and you have to restart learning from scratch. As simple as
>> an example you might put on its front page, it will not get the point
>> across as well as one for a familiar language.
>>
>

[zxq9]

On Thursday 19 June 2014 09:05:43 Karl Nilsson wrote:
> I followed the cowboy getting started tutorial and found it very reassuring
> to be taken all the way to generating a release. I am pretty sure I could
> build on that sample and actually create something that could be used. I
> think there is a lot of value in that. Personally I find tweet sized
> getting started examples very unsatisfactory and prefer something that
> gives and indication of workflow as well as the language. Hipsters may feel
> differently.

Django users certainly don't. The Django documentation and the Python
documentation -- two non-trivial documentation projects if there ever were --
are primary examples of how to speak directly to an open source community in
its own language while making things approachable without dumbing anything
down.

The Postgres docs are another stellar example of documentation, notable
particularly because they are *not* written for the average grade-school
student and have only become popular very, very slowly as (a few elements of)
the web dev crowd have matured and realized that mysql doesn't fit every
purpose.

The Erlang docs already fall into the Postgres category. The challenge is to
explain the *runtime* and its capabilities in a way that compares to the
Django docs -- in particular, how to think of a problem in terms of
independent, concurrent processes (instead of getting bogged down in the
management of concurrency the way teaching the same ideas in C/Java/Python/etc
would) and how to leverage the Erlang system.

The Erlang language itself does not need much explanation. Teaching basic
functional programming paradigms is not the best way for the Erlang community
to use its time -- RWH, LYAH, LYSE, and SICP already do an excellent job of
that. After going through any one of those Erlang is readable.

This whole discussion is still not separating Erlang the language from Erlang
the platform, and it must if we want to understand how popularity works -- and
let's be clear, this whole discussion is an envy-driven brainstorm about how
ubiquitous low-tech could possibly trump something of clear technical
superiority.

[Joe Armstrong]

On Wed, Jun 18, 2014 at 11:02 AM, Loïc Hoguin <es...@ninenines.eu> wrote:

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.

No no no.

You can - Here is an example of a single file cowboy server that computes

fib(N) - 

--- start ws3.es

#!/usr/bin/env escript

% -*- erlang -*-

%%! -smp enable -pa ../erl_github_imports/deps/cowboy/ebin -pa ../erl_github_imports/deps/ranch/ebin -pa ../erl_github_imports/deps/cowlib/ebin 

-mode(compile).

-export([init/3, handle/2, terminate/3]).

main(_) ->

    io:format("ws3:starting~n"),

    ok = application:start(crypto),

    ok = application:start(ranch),

    ok = application:start(cowlib),

    ok = application:start(cowboy),

    Env = os:getenv("HOME"),

    Dispatch = cowboy_router:compile([{'_', [{'_', ?MODULE, Env}]}]),

    

    io:format("Dispatch=~p~n",[Dispatch]),

    io:format("Root=~p~n",[Env]),

    io:format("Info:~p~n",[?MODULE:module_info()]),

    start_http (8124,  Dispatch),

    forever().

start_http(Port, Dispatch) ->

    NumberOfAcceptors = 1000,

    V = cowboy:start_http(http, NumberOfAcceptors, 

 [{port, Port}], 

 [{env, [{dispatch, Dispatch}]}

 ]),

    io:format("Http Running on Port:~w  V=~p~n",[Port, V]).

init({tcp,http}, Req, Env) ->

    io:format("Init~n"),

    {ok, Req, {http, Env}}.

handle(Req, Env) ->

    {Path0,Req1} = cowboy_req:path(Req),

    Path = binary_to_list(Path0),

    io:format("Path=~p~n",[Path]),

    case Path of

"/fib" ->

   {Args, Req2} = cowboy_req:qs_vals(Req1),

   case Args of 

[{<<"n">>,BN}] ->

   N = list_to_integer(binary_to_list(BN)),

   F = fib(N),

   io:format("fib(~p) = ~p~n",[N,F]),

   reply_html(integer_to_list(F), Req2, Env);

_ ->

   reply_html(<<"error">>, Req2, Env)

   end;

_ ->

   reply_html(<<"error">>, Req1, Env)

    end.

reply_html(Obj, Req, Env) ->

    {ok, Req1} = send_page(html, Obj, Req),

    {ok, Req1, Env}.

terminate(Reason,_Req,State) ->

    io:format("Terminated:~p ~p~n",[Reason,State]),

    %% ignore why we terminate

    ok.

fib(0) -> 1;

fib(1) -> 1;

fib(N) when is_integer(N), N > 0 -> 

    fib(N-1) + fib(N-2).

send_page(Type, Data, Req) ->

    cowboy_req:reply(200, [{<<"Content-Type">>,

   list_to_binary(mime_type(Type))}],

    Data, Req).

mime_type(html)     -> "text/html".

forever() ->

    receive

after

   infinity ->

true

end.

--- end

Put this in a file. chmod it to u+x and run it

Then got to http://localhost:8124/fib?n=10

And fib(10) will be returned

Note - I haven't built an application. With a small amount of refactoring this could be

make just as simple as the node.js examples

 The second counter example is rebar? - it's ONE file -

There  are two ways to make single file applications

    1)  make an escript and stick everything in one file. Use the 

         compile flag if you want the escript to be compiled and not interpreted.

     2) make a packed escript that packs all the compiled code into a single file

         rebar is a good example of this

        The code in

        https://github.com/basho/rebar/blob/develop/bootstrap

       is a stand-alone script that builds rebar

       Personally I'm rather surprised that there are so few single file programs

like rebar - they are far easier for the beginner to use and don't break if they

moved to new directories - A single file web server would be very nice to have (hint) ...

 

We have to create an OTP application, compile,

    start the VM with the right paths etc.

No you don't - I have large number of programs that are just erlang modules

started with a top level "erl -s ...." command. 

Both node and java applications require paths to be correctly set, or for files

to be in a particular directory structure.

 

That's not just Cowboy deciding to be more complex than nodejs, that's how Erlang was designed.

 Erlang was not designed to be complex - the primitives in Erlang (spawn_link, trap_exits, etc.) were designed to be as simple as possible and were intended to be called from library routines.

For example, remote procedure calls are not defined in Erlang, but

can be built using send and receive.

If you'd said "OTP was designed for solving more complex problems than node.js"

I'd agree .

[Loïc Hoguin]

On 06/19/2014 01:06 PM, Joe Armstrong wrote:
> You can - Here is an example of a single file cowboy server that computes
> fib(N) -
>

[snip huge file]

>
> Put this in a file. chmod it to u+x and run it
>
> Then got to http://localhost:8124/fib?n=10
>
> And fib(10) will be returned

Joe, your one file example is longer than my many files getting started,
not to mention completely cryptic. The shebang up there isn't something
you can just drop on people, you have to explain it. You also have to
say why you have an infinite receive and how to stop the program. Plus,
doing this you'd also have to explain them that they have to download 3
different projects manually and to put them in the appropriate folder.

And of course, the worst is that by taking this one file example, people
immediately get stuck. How do they add a second handler? I personally
have no idea how to go from that one handler escript to something bigger.

> 2) make a packed escript that packs all the compiled code into a
> single file
> rebar is a good example of this

That script takes an OTP application and bundles it into one escript. It
makes little difference with taking an OTP application and generating a
release, except the release is a lot more useful for servers.

> Erlang was not designed to be complex - the primitives in Erlang
> (spawn_link, trap_exits, etc.) were designed to be as simple as possible
> and were intended to be called from library routines.

I didn't say Erlang was designed to be complex. I'm saying running the
Erlang VM is of higher complexity than dropping a PHP file into a folder
or running nodejs myfile.js. And yes, that's true even if you use escripts.

[Angel Java Lopez]

Sorry, I sent the email to only one person

---------- Forwarded message ----------
From: Angel Java Lopez <ajlop...@gmail.com>
Date: Thu, Jun 19, 2014 at 7:38 AM
Subject: Re: [erlang-questions] node.js vs erlang
To: Pedro Narciso García Revington <p.rev...@gmail.com>

I would like to add:

- Low friction in multiplatform. I gave talks/hands on labs with people with Windows, Linux, OS/X and lots of examples runs at first try

Notice tools like gulp, grunt, that were added to Python, Ruby tool chain, and they were developed in node. Installation of such tools is not an issue, even in different platforms. And adding plugins to such tools using npm, is simple.

Using TDD, writing modules is easy. And you can write modules for browser too.

The nature of require('mymodule') encouraged an ecosystem of modules, most of these are simple. It's like the Erlang modules: the programmer that wrotes the module decides what to export.

Each module, in Node.js, generally expose few functions, and the README.md is all the documentation you need (of course, there are many exceptions, specially when it's not a simple module but a framework).

Angel "Java" Lopez

@ajlopez

On Tue, Jun 17, 2014 at 10:17 AM, Pedro Narciso García Revington <p.rev...@gmail.com> wrote:

Hey Joe

Node is very popular so I'm trying to understand what it is about node that is attractive.

Lots of people already know js, so it seems an easy platform to get in.

What I love about node:

• npm 
  
• modules ecosystem 
  
• easy to deploy 
  
• easy to start: you can use js, you do not need a specific ide, easy to install, good documentation, and examples
  
• tjhollowaychuck: 
  this guy have made lots of projects that makes your life easier: express, mocha, jade, supertest, commander.
  Lots of examples, simplicity, elegant design and good documentation
  https://github.com/visionmedia
• You can develop applications very fast due to javascripts nature (dynamic typing, closures, easy introspection, prototype inheritance)
  
  

2014-06-17 14:41 GMT+02:00 Joe Armstrong <erl...@gmail.com>:

On Tue, Jun 17, 2014 at 2:05 PM, Darach Ennis <dar...@gmail.com> wrote:

Hi all,

For this to be comparable both Erlang and Node.js need to be running

similarly. I don't see how a concurrent Erlang runtime with multiple schedulers

can be compared with a single-threaded Node.js implementation objectively or

fairly...

It's actually the programming models I want to compare and not the

performance - what worries me about node is the run-to-completion

semantics of event callbacks - namely that a long-running event will block

the server preventing short computations from being performed. The

short jobs which could be done immediately have to wait until the long jobs

have finished - this should reflect in the average latencies of a request.

I made a little experiment (a fibonacci server in erlang and node) and fired off

1000 parallel requests to compute fib(N) with N a random number from 10..40.

As I suspected many of the fib(10) events are blocked by ongoing computation of

fib(40) - this reflect in the latencies.

Node is about 1.6 times faster than Erlang - but the latencies for small computations

are terrible - Erlang never blocks so the response times are more predictable.

And yes I know that fib can be offloaded to a background processor or parallelised

in JS with a bit of black magic - but manually converting a long lived computation into

a re-entrant non-blocking version is very difficult.

The node books say something like "make sure that callbacks run-to-completion quickly"

I would say that complying with this advice is extremely difficult. It's very difficult to guess

which computations will take a long time, and even if you know it's difficult to break them into

small re-entrant chunks.

Node is very popular so I'm trying to understand what it is about node that is attractive.

npm for example, looks well engineered and something we could learn from. The node

web servers are easy to setup and run, so I'd like to see if we could make equally 

easy to use Erlang servers.

Performance is not a primary concern - easy of programming and correctness are.

Cheers

/Joe

 

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Miles Fidelman]

Aaron J. Seigo wrote:

>>
>> that's exactly the (non-intuitive) lesson to take away: you can have poor
>> documentation and expect people to do lots of self-training and research BUT
>> if you do these three "simple" things you can still be successful at spreading
>> your tech:

Somehow, I don't think that any of this has much to do with success at
"spreading your tech." Maybe at differentiating your tech, but other
factors dominate which technology people use.

Right of the bat, technology selection is almost always driven by:
1. Absolute dictates of your application environment (e.g., objective-c
for iPad applications)
2. What your employer or client dictates (current employer builds
everything in .NET and MSQL stored procedures, there's an awful lot of
COBOL still out there)
3. A language you learned early, and feel comfortable in - for me,
that's Fortran or LISP, yes it dates me, today schools seem to teach C,
Java, and maybe Python
4. After that, you're into the world of picking the most appropriate
language for the application at hand
- for numerical stuff: Fortran, APL, R, MATLAB
- for mission-critical hard-real-time: Ada (yes, it's alive in both
aerospace and SCADA)
- for web sites: pick a platform/ecosystem first (notably Drupal,
WordPress, Joomla, ..) and one usually ends up at PHP or perl (and for
perl, it's CPAN that makes it)
- now if I'm going to develop a distributed simulator, or a middleware
platform - Erlang is the obvious choice (and if I didn't already know
about it, I'd go looking for something like Erlang, and there's only one
thing I'd find)

Erlang is not taught in mainstream computer science curricula.
Personally, I think it should be - it covers two concepts: Functional
Programming, Actor formalism, and it provides a basis for exploring the
structure of large, complex, highly concurrent, highly available,
distributed systems.

Beyond that, Erlang is something one actively goes looking for - because
it provides unique capabilities ideal for particular classes of problems
that are generally not in the mainstream, and tend to be the purview of
experienced, senior people.

Personally, when someone says "Erlang is too hard to learn" - I think
what they're really saying is:
- the concepts are radically different from what I'm used to (e.g.,
functional programming, actors), and/or,
- my application doesn't require capabilities that are unique to Erlang,
so why bother?

In this context:

>
> 0. attract: tell everyone what your product is really good at in a very
> simple, positive manner[1]

Erlang: highly concurrent, highly distributed, highly available,
near-real-time systems

This kind of narrows the scope rather significantly. And, when you get
into this world, people do serious technology assessment and selection
efforts. Making Erlang a bit better known, and easier to evaluate might
help adoption - but that's questionable - my experience is that people
who are looking for Erlang either know about it, or find it quickly; and
adoption is driven more by political and business decisions than
technical ones.

When it comes to the mass market, Erlang is more likely to be buried in
something else - like a web platform (e.g., Cowboy) or a noSQL database
(e.g., CouchDB). In this regard, the messaging does become important -
but Erlang has very little to do with what makes CouchDB or Cowboy the
right platform for a job.

>>
>> 1. be positive: greet potential adopters with positivity[1] and they will
>> reflect that back

Well, that's more about the community - and the Erlang community is
pretty positive, helpful, and welcoming.

>>
>> 2. have a "quick hook": give people something super quick and super easy to do
>> at the very start. this gives them the feeling of accomplishment, even if it
>> is completely trivial[3]. having tasted success (trivial as it may be) they
>> will invest time/energy to get more.
>>
>> by doing those 3 things, nodejs can have a steep learning curve and still
>> succeed in getting lots of users.
>>
>>

Personally, I think that's irrelevant when it comes to Erlang.
- "Hello, World" is pretty trivial in Erlang, as with any other language
- once you get into real work, Erlang is either overkill, or the
concepts actually require some serious learning

Folks who need Erlang (or something like it) are going in expecting a
steep learning curve, and are not going to be dissuaded by lack of
something trivial.

Just one man's opinion, of course.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Miles Fidelman]

Loïc Hoguin wrote:
> On 06/18/2014 10:22 PM, Kenneth Lundin wrote:
>> That is what I meant, you are using a more complex setup with Erlang in
>> order to get more features. So the comparision with other languages
>> "simple setup" is not fair.
>
> The setup is more complex but the way we get there isn't. Have you
> read the getting started chapter[1]? The release part is smaller than
> it would take to explain "erl -run" or "erl -s": we don't have to
> write extra code for it, we don't have to manually setup paths, we
> don't have to deal with reltool, and so on. It's literally "create
> relx.config, put this in it, run make again". Bam you got a release.
> That part can't get any simpler.
>
> Erlang *is* more complex to use than many other languages (it is still
> simpler than C, C++ and the like though). Either you do things
> manually by downloading dependencies manually and such, or you use a
> build system like erlang.mk (or rebar) to automate things which
> requires you to create an OTP application.

I think that's highly debatable. At least from my perspective, Erlang
ISN'T more complex than many other languages, and is perhaps simpler,
when you factor in the entire ecosystem required to do any kind of
serious work.

For example, to get serious work done in C, you need to know about:
- a text editor or IDE - I wouldn't call emacs, or vim, or Eclipse
trivial to learn
- version control
- language details - including libraries
- program/application structure - header files, linking
- run-time environments and dependencies
- build system (anybody know an easy tutorial for gnutools?, and these
days add in Jenkins)
- packaging system(s)
- logging, monitoring hooks
- and probably stuff I've left out

Java is no different, but is maybe easier to pick up if you already know
all of the above for C:
- OOP is a new set of concepts (but not if you've been doing C++ or
Objective-C)
- you're still using emacs, or vim, or Eclipse
- you're still using git or svn (or switching to something similar)
- when it gets to everything else, there's pretty much a 1-1
relationship between things your familiar with and the new environment
(e.g., gnutools vs. maven, ant, etc.)

In once sense, Erlang is no different - "Hello, World" is easy, it's the
details and the ecosystem that require serious learning. In another
sense, it's different in several key respects:
- the core concepts are unfamiliar to many (functional programming,
actor model)
- the run-time environment is different
- the structure of applications is different (as is the tooling)
I.e., one is not simply learning the same concepts in new clothing. In
that regard, one does have to learn more (unless Erlang is the first
language you learn). But whether it's more complex is debatable (e.g.,
no header files to worry about, no automake, and so forth).

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

_______________________________________________

[Garrett Smith]

It may be worth mentioning that in the survey results, Node.js does not show up as a strong alternative. The usual suspects wrt Erlang alternatives are Go, the JVM languages (largely Clojure and Scala), Haskell, and to a lesser extent Elixir.

One of the contributors to this thread described Node.js as "the biggest crap I ever taste" which, from my own non scientific experience, is not an isolated opinion. I don't know if it's worth investing a lot of energy in reverse engineering the popularity of this platform.

Btw here's the tag cloud for the Erlang language/framework alternatives:

http://www.gar1t.com/presentations/2014-06-10-euc/#slide-76

golang.org was cited many times as an outstanding resource for learning Go.

[Loïc Hoguin]

On 06/19/2014 03:29 PM, Miles Fidelman wrote:
> Loïc Hoguin wrote:
>> On 06/18/2014 10:22 PM, Kenneth Lundin wrote:
>>> That is what I meant, you are using a more complex setup with Erlang in
>>> order to get more features. So the comparision with other languages
>>> "simple setup" is not fair.
>>
>> The setup is more complex but the way we get there isn't. Have you
>> read the getting started chapter[1]? The release part is smaller than
>> it would take to explain "erl -run" or "erl -s": we don't have to
>> write extra code for it, we don't have to manually setup paths, we
>> don't have to deal with reltool, and so on. It's literally "create
>> relx.config, put this in it, run make again". Bam you got a release.
>> That part can't get any simpler.
>>
>> Erlang *is* more complex to use than many other languages (it is still
>> simpler than C, C++ and the like though). Either you do things
>> manually by downloading dependencies manually and such, or you use a
>> build system like erlang.mk (or rebar) to automate things which
>> requires you to create an OTP application.
>
> I think that's highly debatable. At least from my perspective, Erlang
> ISN'T more complex than many other languages, and is perhaps simpler,
> when you factor in the entire ecosystem required to do any kind of
> serious work.

I didn't repeat but what I said was about getting started, and in
particular in a web development setting, where pretty much every other
platform just require you to drop a file in the right folder and you're
done.

Erlang is simpler than C for sure, and I don't know (nor care) about
Java but I wouldn't be surprised if it was simpler too. Only those
aren't really used for web development. (Some people do, but you're a
lot more likely to find a PHP web developer than a C/Java one, at least
in my experience.)

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

[Mahesh Paolini-Subramanya]

"Complexity" is a remarkably loaded term - I'm fairly certain that things that are complex for me (Getting anywhere via mass-transit in Tokyo) are pretty trivial for others (e.g., Loic).

Whats more, complexity of systems has nothing to do with the complexity of the individual components involved (DNA is a bit of a prime example here).

That said, I would claim that erlang systems are more _comprehensible_ than others.  

Mind you, this does require some mastery of erlang, which is not as much of a chicken-and-egg scenario as you might imagine.  

Cheers

--

Mahesh Paolini-Subramanya

That tall bald Indian guy..

Google+  | Blog   | Twitter  | LinkedIn

[Miles Fidelman]

Except that's simply not true, unless you're talking about dropping HTML
files (maybe including JavaScript) into an Apache directory - and even
that assumes that Apache is already set up.

More commonly, we're talking about:
- select a platform (Drupal, Wordpress, Joomla, Plone), install (and,
guess what, not all that easy - particularly if you're wiring it up with
Apache)
- select and install a database
- configure the platform and database
- selection and configure modues
- define pages and behaviors through GUI interfaces
- and then we're into the world of custom module development

The underlying language doesn't enter into the picture at all, except for:
- install-time dependencies
- writing custom modules
- things that are external to the web-site such as database applications

At which point:

> Erlang is simpler than C for sure, and I don't know (nor care) about
> Java but I wouldn't be surprised if it was simpler too. Only those
> aren't really used for web development. (Some people do, but you're a
> lot more likely to find a PHP web developer than a C/Java one, at
> least in my experience.)
>

What exactly are we comparing here? Programming language <>
run-time-environment <> (web) platform <> development environment.

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

_______________________________________________

[Mark Nijhof]

Could a large part of its success be explained by the fact that making anything in either .Net or Java takes such an amount of effort that something like Node is seen as a godsent (which in fairness for a lot uses it really is). Everyone of those devs knows the language well enough to get going.

-Mark

[Mahesh Paolini-Subramanya]

I quite agree - if you just want to get _something_ up, and don't particularly care about any of the long term consequences of your design decisions, you can do far, _far_ worse than an Angular/Node implementation.

And, FWIW, I quite encourage this, odds are that there will be _no_ long term consequences :-)

cheers

[Miles Fidelman]

Mahesh Paolini-Subramanya wrote:
> "Complexity" is a remarkably loaded term - I'm fairly certain that
> things that are complex for me (Getting anywhere via mass-transit in
> Tokyo) are pretty trivial for others (e.g., Loic).

Well, let's say "complex" in an engineering context, for starters.

> Whats more, complexity of systems has nothing to do with the
> complexity of the individual components involved (DNA is a bit of a
> prime example here).

Precisely. I'd venture that one gravitates toward Erlang when one is
building systems and systems-of-systems with lots of distributed, moving
parts (e.g., a telephone switching fabric). If one is building a
single, stand-alone application, I expect Erlang might not be the "best"
choice.

>
> That said, I would claim that erlang systems are more _comprehensible_
> than others.
> Mind you, this does require some mastery of erlang, which is not as
> much of a chicken-and-egg scenario as you might imagine.
>
>

You know, that's a really good point, that highlights two broader
issues: conceptual models, and tooling that maps onto conceptual models:

- Sequential code is relatively easy to conceptualize and represent -
well commented code can suffice as a representation, there are plenty of
debugging and tracing tools for examining run-time behavior

- Object oriented code lends itself to browsers and inspector - though
execution flow can get pretty arcane (at one point, I worked on military
simulators - think game engine - each vehicle was an object, but the
actual work was done by 4 spaghetti coded threads that each ran 20 time
a second - very ugly, and what led me to discover Erlang)

- Actor formalism (i.e., Erlang) - very easy to conceptualize for
applications where things naturally map onto independent processes
(e.g., the above-mentioned simulator -- tanks and airplanes are a lot
easier to model as processes than as objects) - but tools for
visualizing, designing, debugging systems with lots of processes, and
the interactions among them, are close to non-existent (a problem for
Erlang, but also for anyone building highly concurrent, highly
distributed systems)

--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra

[Joe Armstrong]

On Thu, Jun 19, 2014 at 1:33 PM, Loïc Hoguin <es...@ninenines.eu> wrote:

On 06/19/2014 01:06 PM, Joe Armstrong wrote:

You can - Here is an example of a single file cowboy server that computes
fib(N) -

[snip huge file]

 

Put this in a file. chmod it to u+x and run it

Then got to http://localhost:8124/fib?n=10

And fib(10) will be returned

Joe, your one file example is longer than my many files getting started, not to mention completely cryptic.

I *explicitly* said at the end "With a small amount of refactoring this could be

make just as simple as the node.js examples" 

This was a quick cut-and-paste job to show that it could be done - it was *never*

intended an a beginners example.  

To make a beginners example - I'd move most of the code into the libraries and rename

things fro clarity

 

The shebang up there isn't something you can just drop on people, you have to explain it.

Yes

 

You also have to say why you have an infinite receive

Can be refactored out of the code

 

and how to stop the program.

easy

 

Plus, doing this you'd also have to explain them that they have to download 3 different projects manually and to put them in the appropriate folder.

this is what something like npm should do

 

And of course, the worst is that by taking this one file example, people immediately get stuck. How do they add a second handler? I personally have no idea how to go from that one handler escript to something bigger.

read the rebar example at 

        https://github.com/basho/rebar/blob/develop/bootstrap

Actually bigger apps should not be built the same way as smaller apps,

just because large apps need a particular structure, there is no reason why small apps

need the same structure.

      2) make a packed escript that packs all the compiled code into a
single file
          rebar is a good example of this

That script takes an OTP application and bundles it into one escript. It makes little difference with taking an OTP application and generating a release, except the release is a lot more useful for servers.

  Erlang was not designed to be complex - the primitives in Erlang
(spawn_link, trap_exits, etc.) were designed to be as simple as possible
and were intended to be called from library routines.

I didn't say Erlang was designed to be complex. I'm saying running the Erlang VM is of higher complexity than dropping a PHP file into a folder or running nodejs myfile.js. And yes, that's true even if you use escripts.

To run the erlang VM I say

    

     $ erl -s ....

To run node.js I say

     $ node ...

 

 I don't see why one is more complex than the other.

Cheers

/Joe

[Loïc Hoguin]

On 06/19/2014 05:20 PM, Joe Armstrong wrote:
> I *explicitly* said at the end "With a small amount of refactoring this
> could be
> make just as simple as the node.js examples"
>
> This was a quick cut-and-paste job to show that it could be done - it
> was *never*
> intended an a beginners example.
>
> To make a beginners example - I'd move most of the code into the
> libraries and rename
> things fro clarity

Right then we are definitely not talking about the same thing, because
this part of the thread forked into Cowboy's getting started chapter
territory, which is exactly the beginners first steps with Cowboy.

I have no interest in a snippet as small as nodejs, because while
technically more or less possible, it would not at all be representative
of code people actually write.

Confusing beginners with that kind of snippet is not something I see as
any good.

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

[Leonard Boyce]

So with all the complexity issues being talked about would a basic
'app generator' along the lines of yeoman
http://yeoman.io/learning/index.html not be a better fit?

Maybe a binary which can set up the framework for an example
application with the user having to answer a few questions.

Trivial example (assumes name of simperl as binary);

noobie@localhost$ ./simperl

- Choose the application example type:
1) Web Server
2) Multi-server Ping-Pong Example
> 1

- Choose the type of Web Server example
1) Simple "Hello World" web server
2) REST "Hello World" web server
3) ....

> 1
Web Server installed and running. Go to http://localhost:12345/

To modify this server to print "Goodbye World" instead, edit file
"simple_hello_world/src/simple_hello_world.erl"
and use the command "./simperl recomplile simple_hello_world"

For more information on how things actually work see:
simple_hello_world/doc/README.md

noobie@localhost$

By approaching it in this way you may achieve rapid 'satisfaction' and
the ability to expose the user to anything you want with examples of
differing complexity.

Leonard

[Josh Adams]

So with all the complexity issues being talked about would a basic
'app generator' along the lines of yeoman
http://yeoman.io/learning/index.html not be a better fit?

I like everything about this idea to be honest.  It took a while for me to really get down into Erlang as a beginner.  People that haven't been an erlang beginner for a while might not remember so thoroughly.  Anyway, seems good.

-Josh 

[Richard A. O'Keefe]

In another thread, Thomas Lindgren mentioned ToonTalk.
From Ken Kahn's original paper about ToonTalk:
Some of the design principles derived from good construction
toys and video games include:
1. Make the initial experience simple and
gradually increase complexity.
2. Encourage exploration and curiosity.
3. Provide and maintain appealing fantasies.
4. Continually challenge without frustrating.
5. Frequent use of animation and film
techniques and principles (video games only).
...
maybe the difficulty is not in the concepts per se
but their lack of accessible metaphors.

We got a bunch of bills recently, and it occurred to me that
there's probably a good metaphor for Erlang 'receive' there:
messages *arrive* at our house in some definite order, but
we can look at the envelope and decide which one to open first.

The HTMLisation of documentation has made it much much harder
for me to comprehend. It's like the difference between learning
UNIX programming from a jumbled set of man pages and learning
UNIX programming from Stevens' book. What I personally need in
dealing with something like rebar or cowboy is something that
*starts* by explaining
- purpose
- models
- metaphors
I'm still wondering where the rebar manual *is* and why it
wasn't in the release.

I should also say that my experience of npm has not been
positive. There was a program that I very much wanted to
play with that was distributed that way.

Step 1: install npm and get it to work in my environment.
(a day later)
Step 2: install the package.
Step 3: contact developer to find out why that doesn't work.
Step 4: install the package.
Step 5: contact developer to find out why it still doesn't work.
Step 6: install the package.
Step 7: fish around inside the rubble to find a working piece.
(npm was *supposed* to install it in a directly runnable
way. It didn't.)
Step 8: run the program.
Step 9: oh, it's not finished yet.

I'd like to thank Kennita Watson for the First and Second Laws
of Examples:

ONE. There must *BE* examples. Lots of them.

TWO. The examples must WORK. For the user!

[Raoul Duke]

so re: npm

there seem to be 2 kinds of people in the world. 1 is the kind of
person for whom things work and when you tell them it didn't work for
you they look at you like you are dumb/crazy. 2nd is the kind of
person who touches things that everybody else told them were the
shiznit and when they do touch them, they go kablooey. being one of
the 2nd types the fact that so many people seem to be in the 1st
category drives me nuts all too often.

:-}

[Roger Lipscombe]

On 19 June 2014 11:53, John Kemp <jo...@jkemp.net> wrote:
> I try to regularly evaluate new languages and platforms to use, and I doubt
> I'm the only person who does that.

No, you're not the only person who does that. But I think you're
massively underestimating the number of people who *don't* look at new
languages and platforms; or the people who look at a new language or
platform, hit one speed bump and give up on it.

We can't do anything about the first group -- they've learned their
one language and they're sticking to it -- but we can certainly make
it easier for the second group to evaluate Erlang.

How we do that is the tricky part, and I don't think there's a
one-size-fits-all solution. Different people learn in different ways.

I like to learn by taking a simple example, playing with it, taking it
apart and seeing how it works, while dipping into the books,
documentation and man pages occasionally. Others like to do a bunch of
reading up, and _then_ go and play. Still others prefer watching
videos to learn things -- personally I find it impossible to learn
from a video -- but it works for a large number of people.

[Roger Lipscombe]

On 19 June 2014 11:57, zxq9 <zx...@zxq9.com> wrote:
> Django users certainly don't. The Django documentation and the Python
> documentation -- two non-trivial documentation projects if there ever were --
> are primary examples of how to speak directly to an open source community in
> its own language while making things approachable without dumbing anything
> down.

Personally, I find the Python documentation completely unapproachable.
Too many details, too few examples.

[Aaron J. Seigo]

On Thursday, June 19, 2014 12:52:28 Leonard Boyce wrote:
> So with all the complexity issues being talked about would a basic
> 'app generator' along the lines of yeoman
> http://yeoman.io/learning/index.html not be a better fit?

+100

if the templates are written, or at least looked over, by some of the erlang
gurus here that is a very nice way to implicitly pass on best practices to new
developers.

in another project i am involved with, it is obvious when someone has used the
project generator: there is a certain consistency and adherence to coding
norms / idioms that are otherwise unusual to see in code from new comers.

--
Aaron J. Seigo

[Leonard Boyce]

On Fri, Jun 20, 2014 at 5:09 AM, Aaron J. Seigo <ase...@kde.org> wrote:
> On Thursday, June 19, 2014 12:52:28 Leonard Boyce wrote:
>> So with all the complexity issues being talked about would a basic
>> 'app generator' along the lines of yeoman
>> http://yeoman.io/learning/index.html not be a better fit?
>
> +100
>
> if the templates are written, or at least looked over, by some of the erlang
> gurus here that is a very nice way to implicitly pass on best practices to new
> developers.

I was not really thinking about the proposed 'binary' as being a
workhorse app generator, but that's not a bad idea. Now that I think
about it I was probably envisioning something along the lines of a
'erlang by example' app which would allow the new user to be
introduced to the Erlang language and concepts in an simple
interactive format. Begin with immediate satisfaction, throw in a
gentle introduction to syntax via line-by-line explanations of the
basic examples, all the while moving on to more complex paradigms and
code, and all the while exposing targeted links to in-depth
information on the topics being examined.

I believe that the more complexity issues that can be solved through
simple interfaces, the easier it is for someone new to Erlang to focus
on both learning the language and architecture best practices.

I would not class myself as an Erlang expert by any means, although I
use it every day for our entire stack, but I can speak to the
frustration of developers approaching the language for the first time
as I currently 'teaching' Erlang to some of my team who specialize in
JavaScript, but are proficient enough to write code of reasonable
quality in Java, PHP, Python, C# etc

I've had them work through LYSE and sections of Joe's book and now I
have them writing a simple FTP client to support one of our APIs, but
every day I hear their frustration. A few examples below

1) "The syntax is just too weird, I *hate* commas and semi-colons. Why
use a period and not braces?"
2) "What the hell is with the crazy 'defacto' indentation. I don't use
or want to learn to use emacs, I'm perfectly happy with Sublime."
3) "TDD is extremely painful. What should I be writing tests for?"
4) "Why is there no package manager? I need a library for X, where can
I find it? Which one do I use?" When they do find something,
invariably the code has no tests and very little documentation, or
maybe there are multiple options and no clear 'leader'. *or* there is
no library for what they need
5) "No unicode aware/safe string library? wtf? Lists of integers?
Binaries? Why in deities name does it have to be so convoluted?"
6) "Configuration files for rebar et al. just seem weird and sorta
'black magic'. dependency handling, starting of applications etc"
7) "Dialyzer is dog slow"
8) "What's up with the documentation organization? Why do I have to
use google to be able to find anything in the official docs?
Navigating the docs is crazy, I feel like it's still 1998"

> in another project i am involved with, it is obvious when someone has used the
> project generator: there is a certain consistency and adherence to coding
> norms / idioms that are otherwise unusual to see in code from new comers.

By the way Aaron, thanks for all the great work on KDE, I benefit from it daily.

> --
> Aaron J. Seigo

[Loïc Hoguin]

I mean what.

On 06/20/2014 02:54 PM, Leonard Boyce wrote:
> 2) "What the hell is with the crazy 'defacto' indentation. I don't use
> or want to learn to use emacs, I'm perfectly happy with Sublime."

Why the hell are they not using Sublime? What's this 'defacto'
indentation thing you mention? Most people write Erlang in their
favorite editor. I use vim without any plugins myself.

> 3) "TDD is extremely painful. What should I be writing tests for?"

If it's painful then they're not doing it right. They should write tests
for exactly the things they test manually. Doesn't need to be more than
that at the beginning, tests can get added over time.

> 5) "No unicode aware/safe string library? wtf? Lists of integers?
> Binaries? Why in deities name does it have to be so convoluted?"

I'm not sure why they would say that. It's not like JS has good Unicode
support either. Erlang has a number of ICU bindings available if you do
need Unicode though.

> 7) "Dialyzer is dog slow"

Is it? Are they rebuilding the PLT all the time? It never takes more
than 10s to dialyze for me on the bigger projects (usually < 2s though).
Much faster than running tests (especially running tests by hand if
that's what they'd prefer doing).

> 8) "What's up with the documentation organization? Why do I have to
> use google to be able to find anything in the official docs?
> Navigating the docs is crazy, I feel like it's still 1998"

???

http://www.erlang.org/erldoc

It sounds a lot like you/they're making their life harder than it should be.

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

[Mahesh Paolini-Subramanya]

"What Loïc said".

I mean, people have been arguing about Syntax since lord knows when, and its never going to stop.

e.g., Why does Loïc have that stupid "two dots" thing on his name anyhow?  Whats wrong with a good old "i"? The french are sooo <insert gratuitous insult here>.

Syntax is not semantics - this is a pretty hard lesson to learn (not so strangely enough, people that speak more than one language tend to freak out less about this).

Cheers

[Peer Stritzinger]

On 2014-06-20 12:54:38 +0000, Leonard Boyce said:
> 3) "TDD is extremely painful. What should I be writing tests for?"

TDD is by no means mandated by Erlang, this is a matter of taste and
required quality.

With Erlang you can do (as in any other language): write you tests
first and do TDD

Write your tests last.

Write property based tests which rule them all.

And even in the extreme: write no tests at all. Not really
recommending this but you'd still get more stable software if you don't
really test it at all and just run it. Many here have these quickly
hacked together prototypes that amazingly run without problems non-stop
since a year.

> 6) "Configuration files for rebar et al. just seem weird and sorta
> 'black magic'. dependency handling, starting of applications etc"

Rebar is not mandatory at all ... I'm using Erlang since 2007 and never
did anything real with rebar.

If you don't like it don't use it.

> 7) "Dialyzer is dog slow"

Dialyzer is not that slow if used properly (and gotten faster
recently), and you don't have to dialyze on each make.

And if you still hate it: its also optional.

Cheers,
-- Peer

[Leonard Boyce]

On Fri, Jun 20, 2014 at 9:06 AM, Loïc Hoguin <es...@ninenines.eu> wrote:
> I mean what.

It's not a holy war :) This thread has been going for quite a while
and unfortunately for a time warped into a 'cowboy complexity
criticism thread'.
All I'm trying to do is add to the conversation by providing anecdotal
evidence on pain points for those new to Erlang.
I believe there is always value in examining the opinions and
statements of others as they allow us to find ways to possibly
improve.

> On 06/20/2014 02:54 PM, Leonard Boyce wrote:
>>
>> 2) "What the hell is with the crazy 'defacto' indentation. I don't use
>> or want to learn to use emacs, I'm perfectly happy with Sublime."
>
>
> Why the hell are they not using Sublime? What's this 'defacto' indentation
> thing you mention? Most people write Erlang in their favorite editor. I use
> vim without any plugins myself.

They are using Sublime as that's their editor of choice.
When I started learning Erlang I was informed that the 'defacto'
standard for indentation is the indentation used by elang mode for
emacs as this was the primary erlang editor. Maybe I was misinformed,
but that became our coding standard. Others developers use emacs or
ElrIDE (which uses the same indentation as emacs). No other 'popular'
editor correctly supports the 'emacs style' indentation for Erlang.
Maybe it's just me but I like consistency and my mind is 'trained' to
match this indentation format.

>> 3) "TDD is extremely painful. What should I be writing tests for?"
>
>
> If it's painful then they're not doing it right. They should write tests for
> exactly the things they test manually. Doesn't need to be more than that at
> the beginning, tests can get added over time.

Thank you. This is something which is not really covered as an "Erlang
best practice" in anything I've seen to date. My guys want to write
tests for every possible return from every single function. I'm even
seeing tests which are actually testing returns from OTP function
calls.

If anyone knows of any resources for "Best Practices" for erlang
testing I'd appreciate their sharing.

>> 5) "No unicode aware/safe string library? wtf? Lists of integers?
>> Binaries? Why in deities name does it have to be so convoluted?"
>
>
> I'm not sure why they would say that. It's not like JS has good Unicode
> support either. Erlang has a number of ICU bindings available if you do need
> Unicode though.

Again, they're learning and it's a process. In our main project we use
the "ux" library.
But I understand their befuddlement. It just "seems" like something a
language should include.
Seeing the movement over the versions with unicode support I guess
that eventually it may exist.

>> 7) "Dialyzer is dog slow"
>
>
> Is it? Are they rebuilding the PLT all the time? It never takes more than
> 10s to dialyze for me on the bigger projects (usually < 2s though). Much
> faster than running tests (especially running tests by hand if that's what
> they'd prefer doing).

Confession time, I just blindly believed that when I was told. Turns
out they missed reading the "0." in seconds in the timer. His simple
build time was 0m0.45

On the other hand, your pointing this out led me to investigate our
main project makefile. Here it currently takes ~ 15 minutes to run and
basically uses 100% memory and forces swapping.

Maybe someone smarter can point out the error as I certainly cannot see it :(

### snip from Makefile (assume correctly tab indented)
## Dialyzer
DEPSOLVER_PLT=.depsolver_plt
OTP_PLT=.otp_plt
.PHONY: dialyzer

$(DEPSOLVER_PLT):
-dialyzer --output_plt $(OTP_PLT) --build_plt \
--apps erts kernel stdlib crypto public_key mnesia ssl xmerl inets
-dialyzer --output_plt $(DEPSOLVER_PLT) --build_plt \
--apps -r deps

dialyzer: $(DEPSOLVER_PLT)
nice -19 \
dialyzer apps/*/ebin/ --plts $(OTP_PLT) $(DEPSOLVER_PLT) \
-Wrace_conditions \
-Wunmatched_returns \
-Wno_improper_lists
### end snip

>> 8) "What's up with the documentation organization? Why do I have to
>> use google to be able to find anything in the official docs?
>> Navigating the docs is crazy, I feel like it's still 1998"
>
>
> ???
>
> http://www.erlang.org/erldoc

And yet the 1st documentation link on http://www.erlang.org/doc.html
(the title "Erlang/OTP documentation") is to the *non* searchable
version http://www.erlang.org/doc/.
Yes, right in that paragraph is a link to the searchable version, but
if they already have the link to what they're looking for, why would
they even bother reading that paragraph.
Additionally, google search results invariably link to the *non*
searchable documentation.

Maybe changing the link on the paragraph title and explicitly listing
links to both types of documentation in the paragraph body would
prevent this 'mistake'.
I know I made that mistake myself. I was totally unaware the
searchable docs existed.

> It sounds a lot like you/they're making their life harder than it should be.

That could well be the case, and this is why I believe such
discussions are useful as I want to make life easier for all.

Thanks for the response,
Leonard

[Jesper Louis Andersen]

On Fri, Jun 20, 2014 at 4:47 PM, Leonard Boyce <leonar...@lucidlayer.com> wrote:

They are using Sublime as that's their editor of choice.
When I started learning Erlang I was informed that the 'defacto'
standard for indentation is the indentation used by elang mode for
emacs as this was the primary erlang editor. Maybe I was misinformed,
but that became our coding standard.

There is no preferred indentation style for Erlang programs. I've seen god knows everything out there. The language is parsed by an LALR(1) grammar, so identation doesn't matter for scoping either.

I tend to indent code for readability. Some times, another indentation style than the mandated one is far more readable. So even when using emacs, I break the rules now and then. I don't really see that as a problem.

--
J.

[Loïc Hoguin]

On 06/20/2014 04:47 PM, Leonard Boyce wrote:
> On Fri, Jun 20, 2014 at 9:06 AM, Loïc Hoguin <es...@ninenines.eu> wrote:
>> I mean what.
>
> It's not a holy war :)

That was just my reaction, sorry. A more polite kind of "What the .. are
they doing?".

I feel I should write a detailed explanation of my workflow somewhere.
Too often do I read people having too many issues than they should. My
workflow isn't perfect by any means, but it probably wouldn't hurt to
put it into words. (rebar users be damned though, because I don't use it.)

> They are using Sublime as that's their editor of choice.
> When I started learning Erlang I was informed that the 'defacto'
> standard for indentation is the indentation used by elang mode for
> emacs as this was the primary erlang editor. Maybe I was misinformed,
> but that became our coding standard. Others developers use emacs or
> ElrIDE (which uses the same indentation as emacs). No other 'popular'
> editor correctly supports the 'emacs style' indentation for Erlang.
> Maybe it's just me but I like consistency and my mind is 'trained' to
> match this indentation format.

The standard is "indent the same as the code around your change". True
not only for third party projects but also for OTP code.

> Thank you. This is something which is not really covered as an "Erlang
> best practice" in anything I've seen to date. My guys want to write
> tests for every possible return from every single function. I'm even
> seeing tests which are actually testing returns from OTP function
> calls.

If you really want to test all possible cases you should take a look at
property based testing, but beware of the learning curve.

> Maybe someone smarter can point out the error as I certainly cannot see it :(

I do not see it, but if I had to guess I'd say it generates the PLT
every time.

By the way, shameless plug if you like makefiles:
https://github.com/extend/erlang.mk

> And yet the 1st documentation link on http://www.erlang.org/doc.html
> (the title "Erlang/OTP documentation") is to the *non* searchable
> version http://www.erlang.org/doc/.
> Yes, right in that paragraph is a link to the searchable version, but
> if they already have the link to what they're looking for, why would
> they even bother reading that paragraph.

I am not disagreeing with you there, switching the links out would
definitely be better.

[Mark Allen]

I know you probably hate top posting. Sorry. (Not sorry.)

It's a little known feature but rebar does support templates for
generating new OTP applications.

For example:

$ mkdir tmp; cd tmp
$ rebar create-app appid=hello
$ rebar create template=simplesrv srvid=hello_srv

You can make your own rebar templates too, although the docs for doing so
are not very obvious. This was the best I found on github (so far)

https://github.com/mbbx6spp/rebar-templates


Mark

[Bob Ippolito]

mochiweb ships with a rebar template as well, that's how the "make app" target works.

[Paulo F. Oliveira]

"I feel I should write a detailed explanation of my workflow somewhere."

+1

[Josh Adams]

"I feel I should write a detailed explanation of my workflow somewhere."

 

Maybe this would be good to submit to howistart?

http://howistart.org/

https://github.com/howistart/howistart

[Loïc Hoguin]

I have no intention to write a tutorial. Just a series of steps
categorized by situation. "create a library", "create an app",
"prototype", "general maintenance", "fixing bugs", "handling PRs",
"deploying" etc.

--

[zxq9]

On Friday 20 June 2014 09:02:29 Roger Lipscombe wrote:
> On 19 June 2014 11:57, zxq9 <zx...@zxq9.com> wrote:
> > Django users certainly don't. The Django documentation and the Python
> > documentation -- two non-trivial documentation projects if there ever were
> > -- are primary examples of how to speak directly to an open source
> > community in its own language while making things approachable without
> > dumbing anything down.
>
> Personally, I find the Python documentation completely unapproachable.
> Too many details, too few examples.

I've never heard that, but you can hardly be the only one to feel that way. In
your opinion, how does it compare to the Ruby or Perl documentation? Django?

I highlight the Python docs because they provide a complete tutorial and then
pass to the library reference. The tutorial is much more decomposable than
most (its not a walk-through of developing a complete project), and its
surprisingly complete with regard to feature coverage.

You're right that the Python docs do not include many (any?) examples of
complete projects (outside of the package/distribution section), but I believe
they provide sufficient examples of specific features in isolation to be
useful. This seems to be the exact thing you dislike about them. They have
proven useful enough, anyway, that someone totally new to Python can jump into
the code of an existing project and start learning on the fly. It worked for
me (I understand this is a dangerous phrase, though).

Note the Python docs do not teach OOP or FP. I don't think the Erlang docs
should, either.

Perhaps its that complete application-package type examples tend to occur in
framework project documentation, not in language documentation. So, for
example, after skimming over the Python tutorial one can work through the
Django tutorial and publish a simple application from that. From there they
tweak and modify and, viola!, have a trivial thingy running that does what
they like.

But from there, of course, they run into some serious issues. ORMs simply
don't work well for non-trivial cases. The excited coder now is forced to
learn more about Python and to return to the docs, but this time to the
library reference, not the tutorial. At some point he must understand more
about the database bindings that are letting him talk to Postgres, and he
finds relative uniformity among the Django, Python and psycopg2 docs (we can
learn a lot from this detail, I think). Ultimately he must learn about
Postgres itself, and that means learning about relational concepts if he
didn't know them already -- and the Postgres docs fill the gap remarkably
well.

This is a confluence of docs from totally different projects written at an
appropriate level for their purpose. I can't imagine the core Erlang docs ever
being so comprehensive without an absolutely staggering amount of effort.

Few people start with an initial goal of learning Ruby; they start with a
desire to use Rails or work on Puppet or something else -- Ruby is an artifact
of implementation. Few people (who get very far) start with an initial goal of
learning Python, either; most start with a desire to use [any killer app in
Python], and wind up learning a lot about Python along the way. I suppose the
key is to find that killer project everyone wants to work on or killer
framework everyone wants to use -- write it in Erlang, and diligently garden
the docs of that other project.

-Craig

(Sorry for the long message. This turned out to be part live brainstorm and I
don't have enough time to shorten it just now.)

[Raoul Duke]

i for one have a strong dislike for the django docs.

very strong.

[zxq9]

On Friday 20 June 2014 22:22:50 Raoul Duke wrote:
> i for one have a strong dislike for the django docs.
>
> very strong.

Care to elaborate? Unqualified derision does not express anything useful about
what you (would) like.

[Richard A. O'Keefe]

On 21/06/2014, at 2:47 AM, Leonard Boyce wrote:
> They are using Sublime as that's their editor of choice.
> When I started learning Erlang I was informed that the 'defacto'
> standard for indentation is the indentation used by elang mode for
> emacs as this was the primary erlang editor. Maybe I was misinformed,
> but that became our coding standard. Others developers use emacs or
> ElrIDE (which uses the same indentation as emacs). No other 'popular'
> editor correctly supports the 'emacs style' indentation for Erlang.
> Maybe it's just me but I like consistency and my mind is 'trained' to
> match this indentation format.

So? The only time I let a text editor control my indentation
is when slamming a drawer shut on my fingers just isn't enough.
(*Help* my indentation, yes. *Control* it, no way.)
You can get any indentation you want in any text editor you want.

> Again, they're learning and it's a process. In our main project we use
> the "ux" library.
> But I understand their befuddlement. It just "seems" like something a
> language should include.

Hmm. Unicode is *appallingly* complex, and good library support
for it is really important. There aren't actually a lot of
languages that do a good job of it, it is *very* far from being
something you can routinely assume for any programming language.
In an ideal would, we *would* be able to, but in the real world,
we can't *yet* take it for granted.

> Seeing the movement over the versions with unicode support I guess
> that eventually it may exist.

Speaking as someone who has been trying to build reasonable support
for another programming language, I think it's fair to say that
Erlang is moving Unicodewards about as fast as we have any right
to expect. The only thing that will change this is someone with
deep pockets caring enough to fund more work than you would ever
have imagined necessary.

[Raoul Duke]

> Care to elaborate? Unqualified derision does not express anything useful about
> what you (would) like.

how did you know that was my band name?
"Thank you! We are: UNQUALIFIED DERISION! Good night!"

anyway. django docs do this thing that i see elsewhere, too: they have
a story that is the happy path that you have to follow to a T to get
it to stay Happy. if you slightly diverge then often things go to
hell, now or later in the story you are following; if you want to
learn something that isn't in the docs good luck Charlie with that;
etc. it just seems really sorta lame, narrow, patronizing, fluffly,
not really sufficiently helpful, automagic (in a bad way), etc. to me.