way to develop and deliver software. It is way stronger than deployment
in other languages. Again, with erlang, it is not what people are used
to and it may not work great with existing tooling but the reason is
they were way ahead of the other languages and choose a different (imho
better) path. This goes not for basically everything in erlang. It walks
its own way and you may have to re-think what you are used to to
leverage this.
To comment on what dave said (I’ve quoted things in order of when they
appear in the quote but they should’ve likely been re-ordered to make
more sense).
they really weren’t that good at naming things.
Cmon, with applications like mnesia, et, gs, ic, the naming is great!
One of the most confusing names is application.
I think application is the correct meaning. And looking and the examples
above I don’t think “application” even make it to the list of confusing
names.
The only reason for confusion but I think it is because they are used to
terminology from other languages and development environments.
The BEAM is the operating system. An application is a stand-alone unit
which can be started/stopped independently in the OS. They can be
individually upgraded, installed and removed.
In the same line we should then stop calling processes ‘processes’
because it is confusing. They are not processes but co-routines/green
threads or what-ever other terminology you can come up with.
Erlang applications are really just components.
Are the really just components? What is a component? A replacable,
configurable unit? But does it even make sense to start/stop a component?
I think “applications” is more common in erlang than in elixir as I have
a feeling erlang releases was a bit overlooked initially in elixir and I
have seen here on the mailing list that people prefer to include “other
libraries” as part of their own supervision tree rather than running it
as a stand-alone application, and they (I don’t even know I mean with they
here) ship “applications” as only
libraries (but they don’t use library applications (doesn’t make sense
to me)).
I think this is because people aren’t keen on the more static,
not-configured-the-usual-way of erlang releases/applications. And they
provide their own configuration. I see this happening much more in
elixir than other beam languages, probably because people expect certain
things from tooling and if it is not working the way they expect they
tend not to adopt it.
Elixir is likely good for adoption for the BEAM but they also walk away
slightly from the conventional way of doing things which tends to really
well thought-out but “different” from what you are used to.
The Logger, for example,
is an application. The Elixir compiler contains over a dozen.
The logger makes sense as application. You operating system have one as
well (syslog).
Other examples of more “complete” applications are mnesia, dialyzer,
diameter, observer, inets/{ftp,httpc,httpd,tftp}
Then we have “library applications” which I think is almost completely
dropped from elixir. I.e an application you include which doesn’t have a
supervision tree. It is more like the conventional library in other
applications.
There are also ‘included applications’ which may make a lot of sense
but for some reason had a bad reputation both in erlang and elixir
world. An included application is an OTP application which you are
responsible for starting/stopping and which runs in your own supervision
tree. The only “rule” I guess for an embedded application is that it
should only be used in the end release and they should never be used if
you want to re-use a component in another release/application.
So I’m trying to retrain my brain by writing my code as series of separate
applications, each as small as I can make it. A
Good advice. Again, cohesion and decoupling is what is needed. Generally
if something can stand on its own and it has high cohesion then making a
separate OTP application from it makes sense.
Somethings you can use OTP applications to just separate concerns in
your release too. Then you can cheat a little bit on cohesion and have
OTP applications in your umbrella app to be a little bit more dependent
on each other and the reason you have them running as separate
applications is for fault-tolerance and development modularasation.
Enough of the rambling. Please read:
It is a great resource to really understand erlang and it will make you
use the resources available in a better way.
