console

libs like https://docs.rs/tracing/latest/tracing/ (for rust, but i'm sure most languages have things like it) can make logging work for async programs. it achieves it by structuring the log in nested spans, instead of just appending a timestamp and thus losing which async task is related to which log line. alongside with https://github.com/tokio-rs/console it makes log-based debugging for async programs a breeze (tokio-console shows which async tasks are running, like a top(1) but for async tasks, and can show logs of a given task) it's really fundamental to have good logging! both to discover issues as they unfold, and to debug past runs of the program for which you didn't know there was a problem and as such you didn't run the code in a debugger

Yes, we've designed the overall architecture of the system to be modular so that the telemetry can be consumed by a number of different UIs --- we'd love to see someone write web interfaces and/or native GUIs for the console data. I have basically no web development experience whatsoever, though, so I went with the terminal app, because not having to learn JavaScript first made it a lot easier to get started :) We're also thinking about factoring out the Tokio Console command-line application's internal data model and client code into its own library (https://github.com/tokio-rs/console/issues/227) to make it easier to build other UIs on top of that.

Yeah, it is decoupled from Tokio. Tokio emits instrumentation via the `tracing` crate. Tokio Console just listens to the tracing events. Any runtime that emits the same events can be used with Tokio Console. This is the tracking issue: https://github.com/tokio-rs/console/issues/130

Also, thanks for the thought re: digit precision. I am tracking it here: https://github.com/tokio-rs/console/issues/224

There's one in the works: https://github.com/tokio-rs/console

I recently researched this after speccing out which language to choose for some data heavy async apps at work - And the answer is right now, unfortunately, no. Rust is in a bit of a weird place here since as a language it only provides async primitives, and it relies on frameworks bringing their own async runtimes - So the ball is in the Tokio teams' court to provide. It is nice to use channels and tasks in Tokio - The stalwart Rust compiler catches pitfalls with memory leaks and deadlocks that you could fall into with Go. However, observing what's happening within the Tokio runtime is a far cry from where Go and its profiling tools are at. https://github.com/tokio-rs/console - here's an attempt to make a TUI where you can watch everything in motion, which is about as close as you can get to an easy UI into the system.