[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]
Sun Feb 16 22:35:08 CET 2014
On 02/16, Garrett Smith wrote:
> I don't see this coming from today's OTP code. Usability was (clearly)
> never a priority for these modules. e2 tries to wrap this complexity
> and I think does a pretty reasonable job. It could be made easier, but
> I'm inclined to think at that point we're talking about another
> language -- or some serious parse transforms.
This is really the only point I wanted to discuss in more depth in this
list -- I think the rest is something we could discuss in person for a
long time in March.
Anyway, what I could see going is making a basic Erlang project where
all you have is:
- <app>_bridge.erl (supervisor_bridge middleman)
The structure would be
Only <app>.erl is ran by the user and can be, by standard way, made to
need a 'main/1' function running with content similar to an escript. The
rest is generic and can even be provided as a library. With that
approach, start the app by calling 'erl -bridgeapp <app>'.
Alternatively, have the script generate a release config that will do
that stuff for you with a sys.config.
What I like from this approach is that you get:
- OTP's structure and library usage from the community (service-based
- Escript-like capability
- Being able to 'have a main loop'
- Run a release
- The ability to progressively move your non-OTP code to OTP code
without rewriting everything
- You still need to use OTP to publish actual libraries to be fetched by
common build tools, but can run your release as you wish
There are gaps to bridge here and there (does the node shut down on the
main loop ending?), but I think this kind of app could be fairly sweet
to add to get started faster. It's similar to an escript in what you
need to write, but path management and code distribution done through
OTP is much nicer.
More information about the erlang-questions