What are your debugging techniques?

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

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

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.

Yes, most of that book should be directly applicable to Elixir, with a bit of syntax change. The way systems are built, work and interact are basically the same.

For anyone who reads this topic and doesn’t know about observer: :observer.start will make your life easier. It basically is a Task Manager, for inside the BEAM. It gives you a lot of high-level information about what is going on in your system, and it is very useful to, for instance, spot bottlenecks in your message-passing.

Debugging concurrent apps seem to be a reason why debugging „is so hard“. One the other side: for beginners like me - we do not make concurrent apps from start - I would argue that debugging could be more easy.

Does one have experience with the erlang debugger :debugger.start
Debugger — OTP 29.0.2 (debugger 7.0) ?

Yes, I used the Erlang debugger just a bit. There’s a blog post out there about a modification you have to make in order for it to be able to find Elixir sources. Start here, this shows a bit of use, and links to the description of the setup:

In the past 6 years I had the opportunity to work with many excellent Erlang developers and nobody used the debugger tool for nothing. I guess two reasons can be behind the lack of interest:

1., Inserting printout in the code is trivial thanks to hot code reloading.

2., Tracing provided by the VM.

There are several options for tracing, for a newish gui you might want try a beta project called erlyberly: How to trace Elixir nodes with Erlyberly « Plataformatec Blog

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

As above, I do very similar to Qqwy except I log the result. often times with pieces of data from the ENV macro.

Except I use Og, a tiny set of functions that log it instead,

(1..10)
|> Og.log_return() # defaults to debug
|> Enum.map(fn x -> x * x end) 
|> Og.log_return(__ENV__, :info) # will print line, number func and in `info` style
|> Enum.sum
|> Og.log_return(__ENV__, :debug) 

I end up using __ENV__ alot.

Not sure if this is good or not though but it’s helped me.