Stuff Goes Bad: Erlang in Anger (2016)
erlang-in-anger.com
erlang-in-anger.com
* Still good if you work with Elixir
* Good if you have, say, RabbitMQ or Riak in your stack
* Fred knows his stuff.
I'd also love to see something from the other angle: taking a program that's already an instantiation of a complex, distributed architecture, written in e.g. C, and then rewriting it in idiomatic Erlang (or Elixir—especially with GenStage/Flow stuff) to reduce its code size while retaining the same distributed-system properties as its ancestor system.
Remsh and recon are tools I use almost every day.
Chapter 3 planning for overload is useful in general not just for Erlang systems, and is something that is not given enough consideration usually.
In particular the 'fuse' type stuff is really important when you have a real world system where "let it crash!" is not really ok, because you have, say, a user interface, or a web server that should not be part of everything just crashing. In particular, something I've seen: if your Erlang application talks to a database, and the database goes down for some reason, it may be desirable to have the whole application not go down with it!
Thank you!
https://news.ycombinator.com/item?id=8330501 (3 years ago, 54 comments)
https://news.ycombinator.com/item?id=8979267 (3 years ago, 21 comments, dupe)
Hardware has always been a story of reliably operating unreliable parts. It was eye-opening to see the same concepts applied to software.
Fail fast, fail early!
(Also, Erlang did a really good job of lightweight threading, and how that interlaces with things like a cluster of servers.)
Walter Bright has been advocating this for some time:
http://www.drdobbs.com/architecture-and-design/safe-systems-...
See 2.10 Related work.
(I had never heard this idiom before)
It was about improving old/legacy/poorly-built code bases that are in a bad shape and need to be 'rescued'.
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.
Sounds like a great basis for an advanced programming book either way.
{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.