[erlang-questions] node.js vs erlang
Fri Jun 20 22:05:54 CEST 2014
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.
$ 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)
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);
>- Choose the application example type:
>1) Web Server
>2) Multi-server Ping-Pong Example
>- Choose the type of Web Server example
>1) Simple "Hello World" web server
>2) REST "Hello World" web server
>Web Server installed and running. Go to http://localhost:12345/
>To modify this server to print "Goodbye World" instead, edit file
>and use the command "./simperl recomplile simple_hello_world"
>For more information on how things actually work see:
>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
>On Thu, Jun 19, 2014 at 10:12 AM, Miles Fidelman
>> Mahesh Paolini-Subramanya wrote:
>>> "Complexity" is a remarkably loaded term - I'm fairly certain that
>>> that are complex for me (Getting anywhere via mass-transit in Tokyo)
>>> 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
>>> the individual components involved (DNA is a bit of a prime example
>> 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
>> 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
>>> of a chicken-and-egg scenario as you might imagine.
>> You know, that's a really good point, that highlights two broader
>> conceptual models, and tooling that maps onto conceptual models:
>> - Sequential code is relatively easy to conceptualize and represent -
>> 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
>> work was done by 4 spaghetti coded threads that each ran 20 time a
>> 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
>> the above-mentioned simulator -- tanks and airplanes are a lot easier to
>> model as processes than as objects) - but tools for visualizing,
>> debugging systems with lots of processes, and the interactions among
>> 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 mailing list
More information about the erlang-questions