I'm the auhtor of the Erlang article on How I Start. I've felt the same in some ways because it would offer a nice comparison point, but the problem with this i

I'm the auhtor of the Erlang article on How I Start. I've felt the same in some ways because it would offer a nice comparison point, but the problem with this idea is that it doesn't let the authors pick a problem for which they think their tool shines. In a way, forcing the same problem on all authors is more or less risking telling them "you may have to use the wrong tool for this job, but please tell us how you'd do it." Instead, I think the current format is, well first of all nicer for the author (they can pick what inspires them), and also gives you a richer level of content where you may end up learning more than you thought you would. For example, the Erlang text focuses on Releases and shipping Erlang systems, something I felt was still blurry in a lot of people's minds. the Elixir project is done with a concurrent approach that wouldn't necessarily carry over the same way in Ruby, and Ruby's text is showing how to build a gem. Letting the authors pick their subject means they can choose to focus as much as possible on what they feel is trickier with their tool of choice, rather than just showing a given program, for which a site like rosettacode.org might be more interesting.