

We [talko.com] Learned Us Some Erlang - rdtsc
https://medium.com/talko-team-talk-share-do/we-learned-us-some-erlang-ef06bd44e3c2

======
qohen
_For example we end up spending very little time using a debugger and make
much more use of “printf debugging”...and partly because the Erlang debugger
is rudimentary._

Many (most?) Erlang developers use powerful tracing tools for debugging
instead of the debugger, etc. These are built on top of Erlang's native
tracing capabilities, but provide rate-limiting, filtering options, nicer
formatting, etc. They allow one to probe running systems without having to
make code-changes -- an advantage over printf debugging, esp. when dealing
w/systems in production.

Until recently, the tool for this was redbug [0] (which is still used); within
the last year or so, a newer tool called recon [1] came out, which provides
similar tracing functionality [2] as well as some additional features,
including being able to look at memory usage [3], which might help with the
issue raised in the piece.

Recon was written by Fred Hebert's, author of _Learn You Some Erlang_ and also
the author of the free intermediate/advanced book, _Erlang in Anger_ [4],
which describes dealing with issues in production, including memory issues --
he also created the recon demo [5] program described in this book that one can
use to learn the tool -- there are some suggested exercises in the book.

[0] [http://jlouisramblings.blogspot.com/2010/11/tracing-
erlang-p...](http://jlouisramblings.blogspot.com/2010/11/tracing-erlang-
programs-for-fun-and.html)

[1] [https://ferd.github.io/recon/](https://ferd.github.io/recon/)

[2]
[https://ferd.github.io/recon/recon_trace.html](https://ferd.github.io/recon/recon_trace.html)

[3]
[https://ferd.github.io/recon/recon_alloc.html](https://ferd.github.io/recon/recon_alloc.html)

[4] [http://www.erlang-in-anger.com/](http://www.erlang-in-anger.com/)

[5] [https://github.com/ferd/recon_demo](https://github.com/ferd/recon_demo)

