Show HN: Time travel debugger for web development • Hacker News Board

Re: Show HN: Time travel debugger for web development

#221

Post by tedmielczarek » Thu, Sep 23, 2021, 4:07 PM UTC

HeavyStorm wrote: post #217

Lio wrote: post #99

Earlier quoted context omitted.

If you can trigger a debugger from a keyword it's usually pretty easy to trigger it conditionally or on an exception in the code rather than through a GUI. That works well for ruby and javascript and probably lots of others. e.g. something like the equivalent of def foo bar.map do |b| b.do_something! debugger if b.state == :something_youre_interested_in end rescue => e debugger end I'm really excited by Replay. I thi…

Why is that better than using your IDE? Your writing debugging code directly in you production code...

I haven't personally used Replay, but from my experience using rr (a native debugger that also provides time-traveling features) being able to replay execution both backwards and forwards in time on a whim is amazing. These tools excel at diagnosing bugs that are hard to reproduce, because you only have to reproduce the bug once under the debugger and then you can endlessly replay that execution until you figure it out. As Jason said above, you can retroactively add print statements in places that would be useful, without having to waste time trying to reproduce the bug again!

roc (the original author of rr) founded a company to build an even more compelling product on top of rr called Pernosco. They have some mind-blowing demos I'd recommend you check out: https://pernos.co/ .

Being able to easily answer questions like "where did the value in this variable come from, and when did it get set?" makes debugging a wildly different experience.

Re: Show HN: Time travel debugger for web development

#222

Post by tedmielczarek » Thu, Sep 23, 2021, 4:12 PM UTC

Spivak wrote: post #164

bichiliad wrote: post #90

Earlier quoted context omitted.

I think print statements are actually useful in ways that typical debuggers are not meant to be; they make it easy to show changes over time, and they provide a tight feedback loop between observing the value of some data and performing interactions that update that data. For example, if you wanted to know how a coordinate calculation changed as you scrolled the page, print statements would be more useful than a debu…

I've been dreaming forever about writing a debugger that basically just produces a timeline/log (branching in the case of threads or processes) of program execution, you can drill down the stack or into a loop at any point, and surfaces the trace of your code as opposed to 17 layers of library indirection.

I mentioned this in a different thread, but I'd recommend you take a look at Pernosco, a debugging tool written by the original author of rr: https://pernos.co/about/callees/

Re: Show HN: Time travel debugger for web development

#223

Post by tedmielczarek » Thu, Sep 23, 2021, 4:17 PM UTC

milofeynman wrote: post #96

jasonlaster11 wrote: post #4

Co-founder here. It feels incredible to be sharing Replay with all of you. It's been a labor of love the past five years! Replay started off as a simple experiment in what would happen if we added a step back button and rewind button to the Debugger. We quickly realized two things. First, nobody uses breakpoints. Second, being able to share is so much more powerful than being able to rewind. Here’s how Replay works t…

Everyone in the comments is talking about using this for their own debugging, however I think the way to win with this as a business is in two places QA and Automated QA. If you have real human QA people in your org and they could run this while doing QA. If they hit a bug, and could then share a simple link to the dev team that captured their issue + the stack. Same goes with automated QA. Record the UI tests using…

You're right on the mark here. I saw rr used at Mozilla to diagnose and fix flaky tests that failed just often enough in CI to make life miserable, but were nigh-impossible to reproduce in a local development environment. Being able to take that to the next level and collaboratively investigate a bug using a recording that captures it is game-changing technology from the future.

Imagine a world where instead of ignoring, skipping, or marking "known failure" on all those flaky tests your CI hits (we all have them) you could capture recordings of them, and then actually investigate and fix them! That world is possible!