[erlang-questions] node.js vs erlang

Loïc Hoguin essen@REDACTED
Wed Jun 18 13:28:26 CEST 2014


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.

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



More information about the erlang-questions mailing list