Also available:
Slides: https://speakerdeck.com/gvaughn/lets-talk-process-dictionary
Code: https://github.com/gvaughn/process_dictionary_talk

Of course this is right, of course, but I do feel like consciously dividing up pure and impure concerns in your Elixir programs is a powerful design tool. I have been hugely inspired by Gary Bernhardt’s Functional Core, Imperative Shell and @sasajuric’s To Spawn or not to Spawn.

We don’t get all the way to Elm’s side-effect free runtime, obviously, but knowing exactly where those lines our for your own code is a very powerful design strategy. I feel this is why you so heavily advocate—in the talk—for isolation of process dictionary code (preferably in one function).

I hear you though. Elixir’s not pure and it never will be. But I sure learned a ton about how to write Elixir code that I could manage by playing with pure languages.

Looks like a great talk Greg - and I love see references to things said on the forum

Thanks, @JEG2 ! I appreciate the accountability. Those who know me have seen some nits I have picked too I did speak a bit “loosely” in some places.

Funny enough, during a follow-up slack conversation with the first person in Q&A (asking about :rand specifically) I dug in more and realized that yes, it does allow you to pass the seed explicitly. (Aside, I also learned: the older :random library also allows both explicit seed and process dictionary forms, but if you do not initially set the seed explicitly, it’ll set it to 0 so you can have repeatable randomness. “it’s a feature, not a bug”). So, in the bigger picture of Process Dictionary usage, this is a great example of having a pure way of using the library, but also allowing the convenience of the Process Dictionary too! Even better justification for using PD.

I absolutely agree with your I/O point. I was thinking more in terms of the entire system (including the runtime) but did not clarify that point. In any case Elixir is not pure, so the broader point stands.

I really appreciate the discussion, folks. I don’t often get to have this sort of feedback on a talk. Now I’m ready to come up with an improved v2 version of this talk. I think I’ll rename it “Mutants in the BEAM”

@axelson Thanks! It was a lively Q&A, so I felt better about finishing a bit early.

In retrospect, ets was the proper solution for my CSV example. I wouldn’t have wanted to deal with an extra dependency for something so simple. To try to store a map locally would have meant realizing the stream (and pulling all data into memory) sooner with an Enum.reduce to have an accumulator for the lookup values.

Now for the real confession: that code is no longer used in production anyway