Timecraft, a runtime built on WebAssembly that enables time travel debugging | Hacker News Reader

Timecraft, a runtime built on WebAssembly that enables time travel debugging

github.com

20 pointscaust1c13 comments

Written by the folks who wrote the new experimental web-assembly target for Go 1.21:

I would like to point to Spritely Institute, who experimented with time travel debugging in Spritely Goblins and are making use of Object Capabilities, which is their main area of research.

https://spritely.institute/news/spritely-goblins-v0110-relea...

This is a very interesting project, thanks for pointing it out!

What is the recording overhead relative to normal WebAssembly?

What is the average logging rate for a normal application?

What is the worst case application type for recording in time and log rate and what is the overhead?

I do not see any of these primary performance metrics mentioned anywhere obvious.

Thanks for bringing up those questions!

We did not make mention of the performance overhead because we don't have that data to share yet. Timecraft is a young project, and our initial focus is on exploring the use cases that the solution applies to.

That being said, we know that performance is extremely important, and our engineering team has spent a lot of time in their career working on scaling and optimizing large-scale and high-performance systems. Performance will be part of the challenges on our journey, and we're excited for when the time will come to focus on it!

As soon as we have metrics from production workloads that we can release, we'll publish them to share our learnings with our user base. Until then, stay tuned!

I feel like I could make a runtime that enables time travel debugging, it would just cost me a lot of memory.

You're not wrong, software development is costly, and we have a team of bright and experienced engineers tackling this problem!

There is a lot more to timecraft than improving the debugging experience, and we tried to put into perspective some of the opportunities we see in the README.

If you happen to try it out, let us know what you think about the tech!

In case it wasn't super clear I meant like "RAM", not like, human memory?

My bad, I misread your initial comment as "it would cost a lot of money"!

Memory might be the limiting resource to support time travel debugging in some use cases, but for the ones we are targetting, the problem space is a bit more diverse. When multiple machines and multiple languages are involved, and web services are running online on a distributed compute fleet, the variety of challenges to account for goes beyond the amount of hardware that we can throw at the problem.

This is very cool indeed. I might learn golang just for this.

Thanks for the support!

Note that timecraft runs programs compiled to WebAssembly, so the "guest" application that runs on it does not have to be written in Go!

That being said if you're interested in contributing to the project, that will be in Go.

Don't hesitate to reach out on Github if you try it out and have any questions or feedback!

Is source level debugging a possibility with this or does it only cover breakpoints on .wat text?

Source-level debugging is what we have in mind; we have done a lot of work on Wazero and as part of https://github.com/stealthrocket/wzprof to enable it.

It is still not a solved problem, and it requires support for each programming language that does things differently, but we're working towards this.

Reply on news.ycombinator.com