[erlang-questions] node.js vs erlang

[Bob Ippolito]

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


On Fri, Jun 20, 2014 at 1:05 PM, Mark Allen <mallen@REDACTED> wrote:

> 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140620/51951fbc/attachment.htm>