i see, so once i know elixir and phoenix, this book will be the next step.. should I also know OTP and Erlang before this book?
How come this book doesn’t cover elixir 1.4 and phoenix 1.3?
ericmachine88
voger
Definitely you don’t need to know Erlang to follow this book. I don’t know Erlang and I had no problem at all following the book. After all it is an elixir book 
.
You also don’t need to know OTP. This is one of the things this book will teach you.
How come this book doesn’t cover elixir 1.4 and phoenix 1.3?
The book is still in beta. Who knows in what ways the author will change it until the final release.
1
ericmachine88
lance
Author of Functional Web Development with Elixir, OTP, and Phoenix
Thanks for your interest in the book!
I think that if you feel pretty comfortable in Elixir, you’ll be fine. As @voger said, we’ll walk you through all the steps, and you’ll learn a good chunk of OTP along the way. The main element of Phoenix that we work with is a channel, and we’ll build that step by step as well.
When the next beta is released, all the code will work with Elixir 1.4. As things currently stand, for the context of this book, the only thing that will change for Phoenix 1.3 is the pathname to the channel we’ll build and the output of the “tree” command inside a newly generated project. We’ll definitely update those things in an upcoming beta release.
1
mjadczak
I grabbed the book and had a (virtual) leaf through, and I would have two main comments:
First, perhaps I didn’t read the book page properly, but I had the impression going in that this was going to be much more advanced than it was. The PragProg page shows the skill level as “intermediate to expert”, and while I agree that it is not a beginner book, I would not call it expert-level either. By “have previous experience with Phoenix and Elixir” I took “have built complete, if maybe simple, applications with them” rather than “know how the syntax works and how a Phoenix interface is structured”. I think clarifying exactly the target audience of the book may be beneficial.
Second, I take issue with the way that the entire game state is represented in a bunch of processes referring to each other by holding PIDs. I think the best way to say what I mean is to simply refer to this great article by Saša Jurić. The way this is implemented in the book smells really strongly of trying to make Agents behave like objects, which is a common mistake for those moving over from OOP, but should in fact be explicitly called out in a book like this, instead of impliedly encouraged.
I think at a certain point you mentioned that “trying to store the whole game state in a functional tree structure is a recipe for bugs because coordinates can belong to both islands and board and we’d have to update them in both places”. The answer to that problem is to normalise the way you’re storing the coordinate data, so you’re only storing it once. It’s certainly not to make each little piece of your state be a separate process!
As has been discussed many times over on this forum, separate processes should be used when a separate concern, either separate in time or separate in failure domain, is present.
Further, what happens when these processes die? They are all linked it seems, so one failure will take down the entire system. If you insist on using them to model the state, perhaps it is at least an opportune time to put them into a custom Supervisor and use Registry to register them with the coordinate/board they represent?
I’m sure it is not the intention of the book to do so, but while I applaud the decoupled, “Phoenix is not your app” approach, I feel it either itself falls or encourages people to fall into common traps when structuring Elixir apps and modelling their domains therein.
I don’t mean to be too negative—I think the concept of the book is great, and a practical walkthrough of how to build something fun but useful is a great way to convey the concepts, but I also think it’s crucial that the approaches set by the book are 100% defensible (to avoid saying “right”) and push people towards actually using the great many tools Elixir gives us in the way they were designed to be used.
17
hildersantos
Good points! I too think it’s much more advanced than I thought, but so far, so good.
One thing that worried me a bit is the absence of tests, on development cyrcle… but I’m sure the author’s purpose was to be more practical. So, the dev should have a good base before reading the book.
As I said, good points of view!
2
OvermindDL1
Absolutely this! I see this being done wrong in so many places (not just Elixir) in regards to functional design. Normalize the data so if coords need to be shared then have them share an ‘id’ to a coord in some coord storing table. I find data-flow and/or (pure) ECS designs fantastic for this (I use these both in C++ heavily). But they definitely should not be stored in different processes! That is an entirely wrong abstraction here.
Plus everything else @mjadczak said. 
2
redrapids
Author of Adopting Elixir
This is a very good post. This is why I love the Elixir community.
Lance and I are working with some great reviewers to make sure we address this feedback. We’re going to shift the approach for the two chapters in question, the chapter on modeling and the chapter on wrapping the result in OTP.
As a popular book in the community, we want to make sure that the guidance we give is sound.
Thanks again for a great post.
21
martijn
I’d love to learn more about using OTP for the business logic in our web apps, but skipping over persistence makes this kind of pointless. Does it at least describe how to hook into the OTP processes to save their state somewhere?
3
LawJolla
I still got a lot out of the book, but I agree with you. Showing how to store the state and regenerate it is the missing piece.
2