4 ms·

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

20 points by caust1c 3y ago

caust1c 3y ago
Written by the folks who wrote the new experimental web-assembly target for Go 1.21: https://go.dev/blog/go1.21rc https://go.dev/blog/go1.21rc
MuffinFlavored 3y ago
I feel like I could make a runtime that enables time travel debugging, it would just cost me a lot of memory.
- achille-roussel 3y ago
  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!
  - MuffinFlavored 3y ago
    In case it wasn't super clear I meant like "RAM", not like, human memory?
    - achille-roussel 3y ago
      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.
Veserv 3y ago
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.
- achille-roussel 3y ago
  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!
rapnie 3y ago
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-released-time-travel-distributed-debugging-and-more.html https://spritely.institute/news/spritely-goblins-v0110-relea...
- achille-roussel 3y ago
  This is a very interesting project, thanks for pointing it out!
nuc1e0n 3y ago
This is very cool indeed. I might learn golang just for this.
- achille-roussel 3y ago
  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!
  - nuc1e0n 3y ago
    Is source level debugging a possibility with this or does it only cover breakpoints on .wat text?
    - achille-roussel 3y ago
      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 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.

20 points by caust1c 3y ago

Written by the folks who wrote the new experimental web-assembly target for Go 1.21: https://go.dev/blog/go1.21rc https://go.dev/blog/go1.21rc

MuffinFlavored 3y ago

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

achille-roussel 3y ago
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!
- MuffinFlavored 3y ago
  In case it wasn't super clear I meant like "RAM", not like, human memory?
  - achille-roussel 3y ago
    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.

Veserv 3y ago

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.

achille-roussel 3y ago
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!

rapnie 3y ago

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-released-time-travel-distributed-debugging-and-more.html https://spritely.institute/news/spritely-goblins-v0110-relea...

achille-roussel 3y ago
This is a very interesting project, thanks for pointing it out!

nuc1e0n 3y ago

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

achille-roussel 3y ago
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!
- nuc1e0n 3y ago
  Is source level debugging a possibility with this or does it only cover breakpoints on .wat text?
  - achille-roussel 3y ago
    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 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.