It is really interesting to me that this sort of thing didn’t come from programming language folks like I’d expect. You’d think PLs are in the absolute perfect spot to implement things, because they define the semantics and runtime. And there are a few PLs who have time-travel demos, but they’ve never really been seen as more than a cool tech demo.
Perhaps the language is too small a vantage point to really get into what’s happening when debugging.
From the little I have seen, most programming language folks don't seem to care much about debugging. They care a lot about bugs not happening in the first place, which is good, testability is sometimes taken in consideration, but not much about what to do after a bug happened.
No language will prevent you from misimplementing the specs, but languages can be designed in such a way that it easy to trace back why the button is green and not red.
It seems like those who are the most serious about debugging are from the video game industry. They get all the cool stuff with time travel, hot reload, etc... So much that I expected to see something about video games, and was surprised it wasn't.
Coming out of the games industry, I am constantly amazed by how rarely people outside of games use debuggers. And, how slow they are to debug everything because of that...
You’re not wrong, but I do feel like the distributed nature of a lot of systems today is a big reason for that.
And Antithesis is (theoretically) one solution to that, which is very neat!
(I know modern games are also often operating in a distributed environment, but to generalize very broadly, there’s a lot more happening “in one place”)
Unfortunately we do not yet have a way to write reality in any of these languages, so there is always at-least-one-level of translation where errors in representation may creep in.
> Perhaps the language is too small a vantage point to really get into what’s happening when debugging
A little bit. The big thing that others are missing is that it's basically impossible for a PL to accomplish this. Antithesis is basically recording all the state including I/O, network I/O, all RNGS (including the OS) and the big one which everyone has trouble with which is time. So basically you don't need to set up your code and how it interfaces with its environment to be deterministic - you can run within a deterministic container instead which flips the problem on its head and makes it much easier. I'm sure there are tradeoffs. A noteable one is how expensive and slow this approach is vs making your code deterministic. But given how basically no one bothers to make their code deterministic and this is a drop-in solution for scenarios like that, it's really worth it. Additionally, unlike approaches like rr which offer similar capabilities, this is even more generic & not dependent on adding support for every OS interface (e.g. rr doesn't support io_uring yet but I believe antithesis would since it's running at the VM level)
I know time-travel debugging is very very close to Gilad Bracha's heart and something he was really hoping would make its way into Dart.
I don't know to what degree this is true for other language teams but one thing I've observed is that language designers, compiler people, VM people, and IDE/debugger people have more distinct cultures than you might expect. That can make it hard to ship features that cut across those domains. I think we've gotten a lot better at doing that kind of holistic design on the Dart team, but it took years of team-building to get there.
There's reverse debugging and then there's what antithesis does which is a deterministic guarantee of the state. So for example, if you rewind, you'll get the exact same disk & network I/O happening across each call. And it supports arbitrary OS operations whereas typically at the PL level you'll be left at the mercy of whichever OS APIs the PL chooses to support for recording (i.e. similar to rr in terms of what it'll be able to do). Often times, PLs don't even bother with recording state across OS calls since they don't actually know what are OS calls vs normal function calls.
Yeah, I can believe this. I've been working in static analysis for C++ for only 2 years or so, but balancing soundness, precision, and reasonable analysis time really does a number on being more holistic about how to approach these problems. Very much feels like your brain just cannot see other ways to reason about programs because it is so sunk into the current way.
I sometimes wonder if this sort of determinism is the sort of thing that is either designed in from the start of a system/PL, or you need near-hardware level control (like Antithesis).
Yeah it's fun that we get to do this at the hypervisor level. This opens up time-traveling in systems where there's cross-machine or inter-process communication, which really widens what we're able to do.
(I work at Antithesis, if youre interested in chatting more once this thread has gone cold come join discord.gg/antithesis)
Perhaps the language is too small a vantage point to really get into what’s happening when debugging.