[erlang-questions] node.js vs erlang

[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

On 6/19/14 11:52 AM, "Leonard Boyce" <leonard.boyce@REDACTED> 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?
>
>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@REDACTED$ ./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@REDACTED$
>
>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
>
>On Thu, Jun 19, 2014 at 10:12 AM, Miles Fidelman
><mfidelman@REDACTED> wrote:
>> 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
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>_______________________________________________
>erlang-questions mailing list
>erlang-questions@REDACTED
>http://erlang.org/mailman/listinfo/erlang-questions