5 ms·

I don't use Erlang or Elixir but I love the idea of this book. Are there any similar troubleshooting guides for other languages?

dmix 9y ago
There is a book like this for Ruby (on Rails?) which I believe is the inspiration for this Erlang book. I just can't seem to find it at the moment. It was about improving old/legacy/poorly-built code bases that are in a bad shape and need to be 'rescued'.
- mononcqc 9y ago
  I have not read any Rails book ever and they could therefore not be the inspiration for this one :) The true rationale behind the book was to give a better tool to train new coworkers that could help us operate the Erlang routing and logging stacks back when I was still at Heroku, and at the same time to provide similarly useful resources to other people maintaining similar software in the broader community. Most of the operational aspects of Erlang were a bit of black magic, knowing where to dig through experience, having read the right kind of docs, and everyone would carry little gists of incantations and anonymous functions to run on production servers to help figure out what may be going oddly on there by correctly prodding at the VM. I wrote the 'recon' library along with Erlang in Anger so that instead of just being black magic & oral tradition, people would have a better set of well-encoded practices to help approach the debugging and optimization of running systems.
  - dmix 9y ago
    Fair enough, the landing page and description just seemed similar to the one I remember for Ruby, that's all. Although that was more about rescuing a project rather than overcoming common barriers in a programming language. Sounds like a great basis for an advanced programming book either way.
brudgers 9y ago
There is a sense in which it is not possible to write a similar book for other languages. Erlang's "Let it crash" design philosophy is more or less unique among languages used as much as more than Erlang. This means the definition of 'trouble' which requires troubleshooting will tend to be different when trouble is not an error in business logic. Likewise the details of implementing solutions will be different, for example handling a high frequency of crashes by making 10x the number of concurrent actors available to the system. {A Love Song to Erlang} I think Erlang is a beautiful piece of engineering design as engineering design. I would not say that about any other language and find other languages beautifully designed for other reasons. But Erlang is an engineer's tool designed based on engineering principles. The abstractions are engineering abstractions...but with garbage collection.

dmix 9y ago

There is a book like this for Ruby (on Rails?) which I believe is the inspiration for this Erlang book. I just can't seem to find it at the moment. It was about improving old/legacy/poorly-built code bases that are in a bad shape and need to be 'rescued'.

mononcqc 9y ago
I have not read any Rails book ever and they could therefore not be the inspiration for this one :) The true rationale behind the book was to give a better tool to train new coworkers that could help us operate the Erlang routing and logging stacks back when I was still at Heroku, and at the same time to provide similarly useful resources to other people maintaining similar software in the broader community. Most of the operational aspects of Erlang were a bit of black magic, knowing where to dig through experience, having read the right kind of docs, and everyone would carry little gists of incantations and anonymous functions to run on production servers to help figure out what may be going oddly on there by correctly prodding at the VM. I wrote the 'recon' library along with Erlang in Anger so that instead of just being black magic & oral tradition, people would have a better set of well-encoded practices to help approach the debugging and optimization of running systems.
- dmix 9y ago
  Fair enough, the landing page and description just seemed similar to the one I remember for Ruby, that's all. Although that was more about rescuing a project rather than overcoming common barriers in a programming language. Sounds like a great basis for an advanced programming book either way.

brudgers 9y ago

There is a sense in which it is not possible to write a similar book for other languages. Erlang's "Let it crash" design philosophy is more or less unique among languages used as much as more than Erlang. This means the definition of 'trouble' which requires troubleshooting will tend to be different when trouble is not an error in business logic. Likewise the details of implementing solutions will be different, for example handling a high frequency of crashes by making 10x the number of concurrent actors available to the system. {A Love Song to Erlang} I think Erlang is a beautiful piece of engineering design as engineering design. I would not say that about any other language and find other languages beautifully designed for other reasons. But Erlang is an engineer's tool designed based on engineering principles. The abstractions are engineering abstractions...but with garbage collection.