> As far as I can tell you can’t step through tests in the debugger

Rant time. What to do when you write a test framework.

1. When test fails, print everything possible: desired expression, desired value, actual exression, actual value, line and file of failing call. When printing line and file, make the format configurable, with the default being the prevailing standard for the system, so that people can get clickable links in their text editor or terminal with a minimum of hassle.

About 90% of the time, this will give people everything they need in order to at least get started on fixing the failed test

2. Don't make it hard to use the debugger. The remaining 10% of the time, people will need to step through the code. Some measurable fraction of the other 90%, they'll also end up needing to do this, because it looked like it was something simple but actually it was more than that. So don't make this hard

3. See steps 1 and 2

This might sound obvious, but it clearly isn't, because I've used several test frameworks that make running in the debugger rocket science, and print literally nothing but your own message (if even that) when the test fails. Like, you do 'assert.equals(x,y)', and it doesn't even show you what the values of x and y are, let alone figure out that maybe "x!=y" would be an obvious thing to print.

This may not sound like a big deal with my stupid little example, but after you've written several tens of these you will start to see my point.

Slightly related:

The lack of an easy to use debugger is a huge issue for me when working with go.

Coming from PHP, I spend 90% of my time in the debugger running my code line by lines (with xdebug coupled to phpstorm).

A debugger is especially useful when working with other's people code and large softwares. For example, contributing to large Go projects like Kubernetes can be daunting due to the very steep learning curve. This curve would be greatly reduced if we had a good reliable go debugger, which doesn't seem to be the case at the moment. (I'm aware of delve, but last time I looked, it was still fairly complicated to have it work).

How is the debug experience in elixir compared to go ?

Elixir does an amazing job of showing you why a test failed, but as for debugging, up until the latest release, 1.5, there wasn't really a debugger, it had pry, which lets you play around in the environment at the point where pry is called, but you can't step though code. 1.5 introduced a more useful debugging experience, but you can't step line by line, you can only step from breakpoint to breakpoint as far as I'm aware, but I haven't played much with it yet. It's getting there though! I should note that I haven't really lamented the lack of a good debugger, and I came from .NET where I had one of the best debuggers available.

How is the performance of Elixer vs Go? I’ve done some web stuff with Go and I like the performance. Elixir looks interesting. Wanted a reason to give it a try.