Not exactly similar, but in IntelliJ/java one can drop the current frame in the debugger. This jumps one step up in the stack, and allows you to enter the function fresh. Can drop arbitrary many stacks to go backwards.
Of course, it doesn't rollback the heap or any shared state. And playing forward again it will redo things again. So beware of side effects. But in codebases with lots of immutable data structures (Kotlin ftw) it works great.
Combined with hot swapping, one can even drop the frame, change the implementation of the function and then reenter, making it possible to test code changes without spending long time getting back into the same state/context.
Wow! Thank you so much for this comment. I have been using IntelliJ for over 10 years and I never knew this feature existed, I just gave it a try and it's incredibly useful.
One thing I wish Java debuggers supported was the ability to move the instruction pointer to a different line, as has been possible in other debuggers for ages. Is it a JVM limitation maybe? I remember being able to drag the "current line" pointer forwards or backwards in languages like C, C++, and C# in maybe 2003. I wish I could do this with Java; dropping the whole frame is useful but this feature lets you do a lot more, like break out of a loop or skip a block of code you _just_ realized shouldn't execute.
(Replay engineer): We're big fans of RR and pernosco, I love to see those tools get their due. Replay is also designed to support backend programs. We [support Node](https://github.com/RecordReplay/node) today with more runtimes coming soon.
Do you support it only for dynamic languages, where possible to monkey patch code?
All the debuggers mentioned above for the backend work only under Linux, because from what I understand, they use `ptrace` syscall, and on Mac have completely different format, and different capabilities.
Do you plan support Golang, especially on Mac, maybe with custom fork, or similar?
The runtime infrastructure can support all of those. The current recorded browser runs on mac, and the mac image is replayed in a linux backend (with the system calls being handled by the replay engine).
Our initial launch is with a modified Firefox browser on Mac, but the infrastructure itself is generalizable to other runtimes and other operating systems.
However, we do need to "paravirtualize" the runtimes that are recorded on our system (modify the underlying runtime to make it aware that it's being recorded, and do some integration work for each runtime). The design of our system allows for new runtimes to plug in and use all the same infrastructure for replaying.
So the long answer is that we can support them, but support for each runtime will arrive as we prioritize and complete the implementation for them.
Currently we have the mac Firefox-forked browser. In the works we have a chrome browser, nodejs backend, and a firefox fork for windows. But realistically we should be able to support `(any runtime x any os)` within reasonable bounds. Record and replay all the things :)
Of course, it doesn't rollback the heap or any shared state. And playing forward again it will redo things again. So beware of side effects. But in codebases with lots of immutable data structures (Kotlin ftw) it works great.
Combined with hot swapping, one can even drop the frame, change the implementation of the function and then reenter, making it possible to test code changes without spending long time getting back into the same state/context.