I would expect a competent Erlang developer to realize on a conscious and subconscious level that (synchronous) API calls are in fact:
- blocking
- subject to a possible timeout capable of terminating the process
while at the same time using the “let it crash” philosophy and the tools of process links, exits (+ trapping), monitors, supervision, etc. to manage potential termination in some reasonable fashion.
Do you really care if something uses a process
I would at least prefer to know up front whether a function call has the potential to block process execution. Because at that point the decision needs to be made whether it makes sense for the process to be blocked - and if it isn’t, it’s time to spawn a separate process for the express purpose of being blocked (instead).
Elsewhere I already expressed my puzzlement about some places suggesting to choose “call” as a default over “cast”. All too often a “default” is interpreted as a strong preference or worse, a “99% of the time” choice - often accepted to avoid having to actually understand the nuanced consequences of all the available choices.
I think one of the best uses of process state is to store context and correlation information for pending asynchronous requests (i.e. cast messages expected to eventually result in some kind of return message or timeout).
Synchronous API calls have their place but my concern is that mindless adoption (for the sake of convenience) will waste valuable opportunities in process architectures.
In terms of Erlang vs. Elixir - in my experience Erlang educational resources tend to dwell much more on the details of working with the primitives of spawning new processes, sending and receiving (asynchronous) messages - giving the learner a better perspective how different (from more mainstream platforms) the BEAM environment actually is.
Elixir resources seem all too eager to instead impress with agents, tasks etc., without building a sense and appreciation of how really asynchronous the fundamentals are (sometimes leaving neophytes with a false sense of familiarity and security).
