I am trying to get the way Mix works because it is not so obvious when creating a project with it.
The way I understand it application objects are automatically started at runtime I am not quite sure what that means, but I assume that it is when you execute a mix run you run iex -S mix. It looks to me like applications are like the services which run when a computer starts, only in this case they refer to usage of the commands above.
The mod items is where I am a bit confused, ie the module callbacks. It looks to me like the entry points of projects.
Supervised objects are also a bit of mystery, but it seems that in Ecto projects, a supervisor is automatically created to open a connection to the database and keep it running.
It is with escripts that things have become clearer for me. Seeing how the main function takes command line arguments and operates on them make it very obvious what is happening. It is with the others that things are not so clear.
Thanks!
I know it’s not an answer, but one of the things I really like about Elixir (and, to some extent, Erlang as well) is that code tends to be easy to read. So far, if I want to know how X works, digging up the source code for X and reading it will not only give me the answer, but also help me understand more than I usually want ;-). And where most Elixir code is clean, I think the “official” code is exceptionally clean.
Given that OTP is pretty much most-of-an-operating-system, that comparison makes sense. Applications are OTP construct which can be compared to top-level processes in an OS (and processes in OTP them with threads - note, this is a rough comparison).
mod is the entry point of an application - the main routine, if you want. The interface is specified as Application and the most notable callback is start which is the code that should setup an application. You specify it for the current project whereas the dependencies are just specified as “start this application”, but the only reason for this apparent inconsistency is that the dependencies already have their entrypoint defined in their respective projects, of course. So each application, yours and the dependencies’, is specified as “start the application by running module X’ start function”.
Whereas escripts are closer to “normal” applications on a normal OS, in OTP they’re actually a bit of an anomaly and you’re hardly likely to use them for day-to-day work. Applications are the first class citizens here.
It is the Elixir language itself I am primarily interested in. I get the Erlang VM and OTP as a bonus when I need it.
@OvermindDL1 is hoping that someone will create an OCaml target for Elixir, or some other kind of execution model which is not tied to Erlang. Perhaps some enterprising guys will give it a go.
That’s valid, of course, but don’t underestimate the amount of influence that the VM and OTP have exerted on Elixir; understanding the underlying platform is hugely helpful in understanding Elixir. It’s certainly not a language that was dreamt up in a vacuum, like - say - Ruby; it was created to make very good use of an existing platform.
(and the intricacies and quirks of that platform will likely make porting languages not really trivial, unless they happen to have features that happen to match BEAM’s feature set)
