41–50 of 223 posts
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…
Edit: on Ubuntu 18.04 I get the following error:
$ ./replay
./replay: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./replay)
Perhaps a stupid question but is this only really useful if you console.log everything?
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…
Thanks for making this. It's so cool!
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…
It saddens me that a lot of people don't use debuggers and default to adding print statements. As far as I can tell, it's for several reasons:
1. The debugger is primitive (e.g. Godot GDScript - no conditional breakpoints or watches).
2. The debugger is unstable (e.g. Android Studio - frequently hangs, or takes a long time to populate data needlessly)
3. The debugger's UI is not friendly (e.g. Android Studio - hitting a breakpoint in multiple threads causes unexpected jumps or loss of current state; VSCode C++ debugger - doesn't display information properly or easily (arrays of objects) or displays too much information (CPU registers, flags, memory addresses); C++ debugger for D - doesn't display D data types).
4. The debugger is not properly integrated into the environment - can't find symbols, libraries or source files, or finds the wrong source files, etc. Need to jump through hoops to configure those.
5. Platforms don't support debuggers properly (e.g. again Android - ANRs when debugging the main thread, can't leave a debugging session overnight without some timer killing the process)
6. Developers got used to the workflow of "add a print statement, rerun and check the console" since high school and nobody taught them a more powerful tool
7. Developers code all day, so adding print statements by coding feels more natural than switching to the debugger's UI and way of doing things. (e.g. "if (i == 100) console.log(value)" allows you to stay in the same code, as opposed to setting a breakpoint, finding out how to add the 'i == 100' condition and pray that there's no issue with variables being optimized out at runtime).
I like Replay's features and that it's improving the state of the current tools. At the end of the day, adding print statements in Replay doesn't seem to affect the state of the application, so in that sense it's similar to gdb commands in that it's just a UI choice, but I wouldn't go as far as encouraging print-based debugging.
Outside of Replay, print-based debugging is still a primitive way of analyzing the state of the app and promoting this state of affairs reduces the pool of people who use and would hopefully improve the existing debuggers.
We all appreciated Firebug and the Chrome DevTools because of the powerful features they give us to inspect the state of the application. Imagine a person who adds print statements to their code every time they want to inspect the DOM or check the current CSS attributes. It works, but we have better tools, and we should make them even better.
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…
Lost me here, using breakpoints are an invaluable tool for people that actually take the time to use their tools correctly.
Perhaps a stupid question but is this only really useful if you console.log everything?
(Replay engineer): We support all the debugger features (breakpoints, step in to, step over) and more (step back). We emphasize console.log because we found that time traveling console.logs makes for a good demo, and engineers immediately grok what is it capable of, rather than think that they need to adopt a whole new debugging workflow to use Replay.
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…
The problem with breakpoints is my loop runs 1000 times and I only care about the one time it errors. Making watch logic for that sometimes is too complicated or changes the outcome (race conditions especially). This seems like a great solution. I'll be checking it out!
- https://undo.io/ (It can also support Golang https://docs.undo.io/GoDelve.html)
- Mozilla RR https://rr-project.org/
- GDB https://www.gnu.org/software/gdb/news/reversible.html
Unfortunately, works only in Linux.
Earlier quoted context omitted.
> Every once in a while a piece of technology comes around that doesn't quite have an equivalent. I dunno, https://www.rrweb.io/ comes close (closer?) and it's open source. There's also other paid solutions like FullStory and LogRocket.
I agree there's a lot of session replay style equivilents (and rrweb is great!), though what Replay is doing unfortunately cannot be done in production in the same way. In the ideal world this level of data could be extracted from production incidents without an individual running specialized software, but with the state of technology I'd say they're both aiming to solve different problems.