<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 14, 2016 at 7:29 PM, Ryan Stewart <span dir="ltr"><<a href="mailto:zzantozz@gmail.com" target="_blank">zzantozz@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Q: Are there third-party libraries that you almost automatically include when you start or become involved with an Erlang project?</blockquote></div><br>Just mentioning the three most important:</div><div class="gmail_extra"><br></div><div class="gmail_extra">Feuerlabs Exometer_core - You need a way to add metrics into your system so you know what is going on. Usually, I'm willing to sacrifice a lot of raw processing power on a node if the upshot is I know what is going on inside the node. In distributed systems, much slowdown is not your own code, but the interaction with foreign code. Knowing what time properties the foreign systems have will make it much easier to pinpoint where an eventual problem is in your own system.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Fred Hebert's Recon - when things start going wrong, it is nice to be able to trace the application. Nowadays, I add relatively little debug log statements. I just trace the system instead.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ulf Wiger's gproc (alternative: Ostinelli's syn) - gproc works around the limit of local process registration: you can only register an atom, not an arbitrary term. It also lets you subscribe to changes, which is really nice when a system tries to recover from failure. You can demand certain processes exist before you continue.<br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>