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.

Thanks for the hat-tip! I’m beyond excited for the beta launch.

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.

Wow - this is just above and beyond. Drastic “mid-voyage course correction” despite the consequences, dedication to a quality product, you have to respect that!

So - don’t bother with any more errata?

Sometimes, beta happens. We just got some great technical feedback from people we trust in the Elixir community. Since the book is so far along, the feedback was especially painful, but we have decided to incorporate it before we go forward with the rest of the book. We chose to use Agents as a way to approach OTP, but we overused them. Unfortunately, that sent the wrong message about good application design in Elixir, and we sincerely apologize for that. The next beta will put functional principles front and center. We’ll use separate processes only when the design calls for them, and we’ll stick to plain modules and functions when it doesn’t. So you’re getting a better book. The downside is that it will take some time. You won’t see the next beta version until approximately mid-May. Know that we have your best interests in mind. As one of the more popular Elixir books right now, we want our guidance to be rock solid, so we’re enlisting some great talent in our review process to improve the book. Since it’s delaying our betas, we wanted you to know.

Thanks for your readership and your patience.

Thanks so much for your support @peerreynders!

I’ll be honest, rewriting chapters is no fun, but what would be worse is releasing a book that isn’t the absolute best it can be.

For your errata question, if you have any for chapters 6 and 7, send them along. I would say it’s probably better to hold off on any for the other chapters for now.