From Erlang's perspective, debugging an average distributed application is just like being primitives hunting in the forest directly after graduating from colle

From Erlang's perspective, debugging an average distributed application is just like being primitives hunting in the forest directly after graduating from college. I mean, there's even no parameter in the call stack, people can only guess instead of knowing things for sure. Of course, there are more important things like remote debugging in Erlang. To fix a production issue is like fixing a plane that is malfunctioned and crashing: For average language and runtime, the plan is to take a guess, then develop a theory, build a malfunctioned plane according to the theory. If it's not having same issue, repeat previous steps until people rebuild a plane having exact same issue as the crashing one. Then fix the plane having the same issue, and apply it to the crashing plane. For Erlang, the process would be, examine the malfunctioned plane to see where the problem is for sure, directly patch it in place to make it usable again. And then build a real fix, applying it without restart anything. Tools may not be the most useful things in the world but they definitely could be game-changers sometimes.