[erlang-questions] Fwd: Must and May convention

zxq9 <>
Thu Sep 28 12:12:26 CEST 2017

On 2017年09月28日 木曜日 11:38:08 you wrote:
> > No messaging, no external resource calls, no ets, no nifs, certain
> functions in io and io_lib are out, etc.
> So each function sending a message out is impure by definition, therefore
> all gen_server calls are impure too. Meaning -pure declarations are
> applicable only to a narrow subset of all functions defined. I just wonder
> how many paths are in a graph of calls not involving calls to gen_server:*
> family in a typical Erlang application.


What winds up being pure is your implementation of how you react to all
those messages.

If you write code with the deliberate intention of making as much of
your code pure as possible you wind up with quite a few very happy side
effects (no pun intended). You start building side-effecty message and
IO bussing procedures that involve dispatch to implementation functions
that do the actual work of processing your values -- and all of those
become provable. This naturally separates transport from processing,
and a set of useful outcomes within your own mind and your development
team tend to result.

I don't know how to go about quantifying those effects -- but doing things
like onboarding new team members is markedly easier and the time between
them showing up (perhaps not knowing Erlang) and contributing more than
distractions to the effort is MUCH shorter.

The bottom line is that passing stuff around is NOT the main job of your
program in most cases, manging some problem of the real world usually is.
Incident to that, you model the problem in two ways: the path and manner
of how messages move around, and within processes how the values involved
are processed. The value processing parts are sequential, procedural, and
can be proven and made pure. The message passing is messy, unprovable,
in a sense unreliable, subject to random timing, and a bunch of other
effects that derive from the fact that the real world actually works that
way, and these aspects make that half of any concurrent solution chaotic
and unprovable.

You'll get a lot more mileage out of a pure type graph in, say, a business
data processing system (something like 80/20 pure/impure) than a chat or
comment threading system (something more like 20/80). In simulation systems
like game servers you get about 50/50 -- which is still a huge win because
a lot of the processing involved is subtle and really needs to be property
tested lest you invent some wacky emergent behaviors that players will
exploit almost instantly as if by magic.

These are tools to make better software and, most importantly, help us
understand what we are actually trying to do. In this sort of inherently
messy effort the perfect is absolutely the enemy of the good.


More information about the erlang-questions mailing list