From my modest understanding of Plugs, they work like function calls, and in Phoenix you call them, so you can always follow the control-flow. As opposed to Rai

From my modest understanding of Plugs, they work like function calls, and in Phoenix you call them, so you can always follow the control-flow. As opposed to Rails’ where you write («magic») methods which you have to trust the framework will call at some point (IoC). I may be wrong, but that’s atleast what I meant. To your second point: On one hand the article serves as my own summary notes of what I’ve found desirable features (plus why), and maybe could serve as inspiration for a new language spec someday. Matz found it inspirational, at least: https://twitter.com/yukihiro_matz/status/1451548965019668489?s=21 https://twitter.com/yukihiro_matz/status/1451548965019668489... The article links to many tremendous talks and writings, from various thought-leaders and pioneers, after all. I’ve just collated the principles and features I have become convinced are valuable. On the other hand, since the context is language design, the purpose is to understand what features are generally considered good, so even a collection of favorite features or pet peeves can be a starting point for that, at least for shared discussion. The point is furthermore to find the good and avoid the bad, not gripe over all the peculiar cases of bad, of course. Many of the points also have a brief justification or further reference, that can also be helpful, and discussed (agreed to, or refuted). I don’t have all the answers, and teasing out which points are actually conflicting, either from my oversight/inconsistency, or from fundamental mutual exclusivity, is part of the discussion. A discussion that would especially benefit any whom the dream may resonnate with. So I am grateful that you are pointing out any flaws or inconsistencies as you see them.