How would you call modules that work by using processes? Services? Dynamic Erlang modules? (Can’t really call them behaviours because there are cases when they are not used).
A module that is a set of functions seems to be more straightforward as it could be called a library. But then again, that module could also utilize one-off processes so the previous description could also fit here…
A concrete example would be the SASL application which comprises
Background for this question
Was reading Adopting Erlang to get into using Rebar3, and the Releases chapter mentions that even though
rebar3 new release command will always include
sasl in the
relx template in
rebar.config, the examples in the chapter removed it “since we are focused here on creating containers which are replaced instead of live upgraded so sasl does not need to be included.”
Trying to convert an old project into a proper OTP application and release, but not using containers (yet) so looked the SASL docs whether I should include it or not. In the end, I had to look into the source to figure out as I found the wording of the docs confusing - but also realized that I have no clue how they could be made less ambiguous…
For example, the SASL User’s Guide’s Introduction starts with
The SASL application provides support for:
- Error logging
- Alarm handling
- Release handling
- Report browsing
systools) and the
sasl man page in the Reference Manual uses the word “services”
The SASL application provides the following services:
but “service” doesn’t feel right here.
The application-related terminology in Adopting Erlang is great but then parts of an application is a different kettle of fish.
we’re going to use the following terminology for OTP Applications for this entire book:
- Library Applications: stateless collections of modules
- Runnable Applications: OTP applications that start stateful supervision tree structures with processes running in them
- OTP Applications: either Library or Runnable Applications, interchangeably
For some weird reason I couldn’t edit my post above by adding new links so here’s a reply:
Came across a couple of Erlang glossaries (1, 2) to find the right term, but no joy. (Why was the glossary remove from the Erlang docs? The old one is only available through the Internet Archive…)
I’m find this link Glossary. Just put
Glossary in search field https://www.erlang.org.
I would generally just call the stateful processes’ modules by what behaviour they implement: a server, a state machine, and event handler, etc.
The others I’d probably just call a module, or to be specific, a “functional module” (a module can be stateful and process-free if you ask to pass state around and there is an expected protocol or order for calls to happen with).
Note that this is a nomenclature that I would use to describe internal details of the implementation, whereas to a user, I would likely focus more on the functionality and types of calls, and focus on available operations more than implementations (so that I’m free to change the implementation at a later point).
In the later case, the divide between process-based or not will be based on whether the interface/API appears to look mutable or not. Anything that looks mutable is possibly built on message passing, ETS, network calls, disk operations, etc. Anything that is referentially transparent (you carry state around if any) is likely to be functional (unless it relies on hidden configuration values that are stateful or handle coordination!) – the ability to change these without promises is good and a sign of abstraction that successfully decouples implementation details from core concerns, but you generally can’t alternate between mutable and immutable without breaking changes, so you have to commit to one.
SASL is a bit of an odd thing because it is a single OTP applications, but it arguably implements multiple things that could also live in distinct applications (you have outlined them in the op). But that it focuses on the names and functionality rather than telling you how it’s implemented is actually decent design from that point of view.
Thank you for the detailed reply!
Initially, I planned to submit a PR to suggest clarifications to the SASL docs, but your answer brings up a lot of stuff that I haven’t even considered. Ultimately, none of my proposed changes would have made that much better, and was able to resolve my misunderstandings (even with my modest Erlang skills) just but taking a quick peek under the hood.