Programming Elixir ≥1.6: Functional |> Concurrent |> Pragmatic |> Fun by Dave Thomas.
Some of Dave’s words I found particularly interesting, insightful, or inspiring.
“But mostly, I want you to have fun.”
“…you can think about programming in a different way.”
“You no longer have to think too hard about protecting your data consistency in a multithreaded environment.”
“I don’t want to hide data. I want to transform it.”
[Read More]Lowercase sigils interpolate their parameters, uppercase sigils do not.
User-defined sigils are not globally available. Need to be imported. Reduces the risk of running into a system-defined sigil.
Protocols remind me of Python’s duck typing.
[Read More]An Elixir behaviour is a list of functions a module is expected to implement.
[Read More]My interest is in application development so macros are not something I expect to ever be creating. So this is mostly a chapter for reading.
Did work through the first two exercises. Took awhile for me to understand that I cannot use a macro-defined function in the module where it was expanded. Makes sense since Elixir first compiles then loads, so the dynamically-created function isn’t available for use.
[Read More]Agents are processes that maintain state.
Effectively, this is wrapping the Stack.Stash process we’ve implemented earlier.
Ran into significant issues between outdated Distillery information and incompatibility with OTP 25.
A day for reading and playing with Dave’s code.
I’ll be keeping the duper source around for future reference to starting multiple servers.
In order to reliably remember a value, we spin up a process that does nothing except remembering. This isolates the information storage, which has maximal reliability, from information manipulation, which can have all sorts of problems.
[Read More]Dave discusses an alternate component-based approach to writing GenServers. This consists of modules in three files:
The public API is just a wrapper to the GenServer functions and the GenServer functions are just a wrapper to the implementation. This hides the GenServer call/cast complexity and isolates the implementation.
I like this approach, but think that breaking it into three files is too complex. If the public API is only a wrapper to the GenServer API and the GenServer API is only a wrapper to the implementation, we can easily put them into a single file.
My approach implements the GenServer in two files: