You have to be very careful when debugging things in a concurrent environment, at least when you debug in a more traditional way which stops and controls execution. Anything that is waiting for the debugged process will hang and in many cases may time out and crash, which is not what was intended. Also doing something like IEx.pry in a function which is called in many processes will also be interesting.

Sorry to sound very negative here but having very concurrent systems does change you need to work with them. Sometimes IO.inspect is all that is reasonable. Or use the built-in tracing facilities.

Robert

Because of the ability to run multiple Erlang applications side-by-side in the same process and because of metaprogramming awesomeness, one of the fancy things you can do is IEX.pry(after you require IEx in the module) , which starts a shell at that current location in the code, so you can debug the scope you are in.

The cool thing about IO.inspect by the way is that you can plug it in everywhere in your pipelines without altering the result:

(1..10)
|> IO.inspect
|> Enum.map(fn x -> x * x end) 
|> IO.inspect
|> Enum.sum
|> IO.inspect

I think that we, as a community, need to study our options for inspecting our applications. As others has mentioned in this thread: The Beam is a different beast. Introducing break points changes the program and such.

Personally I have to look into this book: http://www.erlang-in-anger.com. It is another Erlang book, but learning a little bit of Erlang goes a long way :)—it describes strategies for tracing and probing a running Erlang system.