Any respectable programming language that has deployments consisting of millions of lines of code running in thousands of installations worldwide must provide built-in low-level tracing mechanisms on which to build tools that can be used for live troubleshooting. Languages that don’t provide these tools put a huge burden on developers and support engineers alike, as they have to either develop this infrastructure from scratch themselves or troubleshoot their systems in a black-box environment.
In Erlang, Ericsson’s experiences of tracing live telephony switches are reflected in the trace BIFs, which, from being part of the first version of the language, have evolved through the years to become the foundation for a set of tools that give full visibility to the changing state of the system and, as a result, drastically reduce bug resolution times and troubleshooting efforts.
Imagine you receive a bug report from a live system, where you get
badmatch error when
pattern matching the result of the call
You expect your program to pattern-match on an atom denoting a message
type, but instead it terminates when coming across the tuple
You can quickly establish that the database got corrupted and set
about trying to find the
ets:insert/2 call that wrote the entry into the ETS table. As messages entering the system are tested at the system boundary, this message should ...