Show HN: CodeTracer – A new time-traveling debugger implemented in Nim and Rust

The planned RR recordings integration is what I'm most excited about though. Having this capability for systems languages like Rust and C++ would be transformative for complex debugging scenarios where you're often forced to restart debugging sessions from scratch after stepping past a crucial point.

I see, I see. And what is a SNARK proving system?

Thank you!

The Python initial prototype is not yet finished. It's easy to play with, so anyone interested can actually work on it! Currently, in the experimental tracers, Ruby is usable for smaller programs, so one can try Ruby immediately.

I do plan on improving some of the prototypes, and on adding additional ones: for Lua, but JavaScript: e.g. v8 is also a good target. Scripting language users that find it useful, are welcome to discuss/chat with us, or even directly contribute or propose support for new languages.

A form of record filtering is planned indeed.

We have experimented with automatic chart visualizations of some things, we've planned custom visual representation as well, great to see interest in those

> Wish there was also for JS/TS.

There’s Replay for browsers and Wallaby for Node.

We are also planning to develop a distributed tracing platform, similar to Jaeger and OpenTelemetry, that continuously records the execution of many distributed processes (e.g. micro-services).

Unlike the existing platforms, which capture only message flows and require you to make educated guesses when some anomaly is observed, our system will let you accurately replay the processing code for each message to quickly identify the root cause for the anomaly.

This would rely on our ability to jump to the specific moment in time when a certain incoming message starts being processed. This moment can be identified either by a log line with a specific format or by a call to some special tracking function (e.g. track_incoming_message(request_id)).

For the system languages, the RR[1] recordings try to be practical by capturing only the non-deterministic events in the program execution. You can pair this with a ring buffer that discards the data after a certain retention period.

For the scripting languages(or any implementation using the db-like traces) we might add some advanced record filtering options.

(But maybe we are misunderstanding the question?)

1: https://rr-project.org/

Especially since the trace files are in .json. [0]

[0] https://github.com/metacraft-labs/runtime_tracing#format

We are currently working on two "backends" where recording works in different ways.

For the scripting languages and smart contract/ZK languages, we instrument the interpreters using high level hooking API-s or direct patches, and we produce a trace.

For system languages, we directly build on top of RR[1] recordings for now: RR can record multiple processes, and it works in userland. IIRC it doesn't support modifications of shared memory outside of the recording. It's very well documented in their paper: Engineering Record And Replay For Deployability: Extended Technical Report[2].

1: https://rr-project.org/ 2: https://arxiv.org/abs/1705.05937

We are building our future support for the system languages for now directly on top of RR recordings: credit to Robert(roca) and Kyle and all other contributors for RR and Pernosco, they're amazing technologies.

We've researched possible alternative approaches/tools as well, especially keeping in mind Windows/Mac support.

The traces for Noir and the scripting languages work in a completely different way, capturing all the relevant data which is later indexed into a db-like structure. With some future optimizations this can be very useful for various shorter programs in scripting languages, and generally for blockchain languages(as the running time there is usually low) and we hope that eventually with flexible record filtering it can be practical even for capturing important segments/aspects of long-running real world projects.