Have you delved at all into the potential for having a true "rust repl"? This is something I have very much wanted for some time, where instead of just recompiling and re-running everything every time, it just compiles the new line and executes it in the memory context of the already running rust program. I'm just not enough of a low level rust hacker to get it working, but imagine the web frameworks and things that could exist with a good REPL for rapid debugging and prototyping in rust.

I actually spent a whole summer trying to do this in Crystal and I was very nearly successful, however a few low level limitations got in my way at the end of the day. In Crystal it is actually possible to do this kind of REPL if you have a perfect ability to deep marshal/copy any object, and I almost, almost got that working here: https://github.com/sam0x17/marshal

I think a low effort, high value step in the usability direction of a REPL is cargo-script

I've written some on it [0] and there was a recent reddit thread discussing it [1]

[0] https://epage.github.io/blog/2021/09/learning-rust/

[1] https://www.reddit.com/r/rust/comments/rddokp/media_most_up_...

Something like that would definitely be useful! It's not really in scope for this project, which is intended as a telemetry and diagnostics tool, but I can imagine a Rust REPL being useful. Of course, in order to do that, you'd need to implement a general-purpose Rust interpreter, which seems like a fairly large amount of work.

In practice, I personally just use REPLs mostly for quick testing out of a small expression or something...and honestly, I usually just use the Rust playground (https://play.rust-lang.org/) for this. Small examples are compiled fast enough in the playground that it's kind of a REPL-like experience for testing stuff out semi-interactively...but it's not the same as connecting to a running application and running new code inside of that application. That's something that seems very difficult to add to Rust, a compiled, statically-linked language with limited support for hot reloading...

There is https://github.com/google/evcxr/blob/main/evcxr_repl/README....

Can tokio-console be used on Rust async programs that don't use the tokio runtime (assuming such arises on desktop)?

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

`valuable`[1] was initially written to support tracing, but I see this 0.1 release doesn't use it. Is valuable seen as more of an add-on to this approach, rather than core to it?

[1]: https://tokio.rs/blog/2021-05-valuable

The current release of `tracing` includes the predecessor of valuable (https://docs.rs/tracing-core/latest/tracing_core/span/struct...). Valuable extracts this functionality and improves on it, but hasn't quite made its way back into tracing yet. I expect that it will be included in upcoming releases (I know eliza has been poking me to release valuable and get it in tracing, I probably should get on that!)

Yeah, the goal is for `valuable` to replace `tracing`'s (currently much more limited) `Value` trait entirely, when we release `tracing` 0.2. Before making a breaking change, though, we want to release opt-in support for `valuable` in the current v0.1.x `tracing` ecosystem, so people can start trying it out and we can figure out if there's anything missing.

You can follow the progress of that here: https://github.com/tokio-rs/tracing/pull/1608

I believe it's currently just waiting for a crates.io release of `valuable`!

This looks great! I wonder how hard it would be to add support for this to debuggers like lldb. I believe they currently lack a way to inspect rust objects.

I stopped following development of `valuable` since I was too busy with non-rust-stuff, but weren't there still some big API-shaping questions open for it?

Not too many now. What it really needs is real usage to find any potential limitations.

What's the intended workflow? Would I run a console an all of my rust services, and then when debugging some prod issue connect to it? Or would I flip a switch? Or is it more for CLIs?

Curious to hear, in general, how it's been used.

This first release is geared primarily towards local debugging. That said, it is designed to be able to enable / disable instrumentation at runtime and it will be able to support connecting to a process in production, enable the instrumentation, and debug there.

Right now, we wanted to get the first release out and start getting people using it and collect feedback to help prioritize future development.

Got it, thanks. A follow up - is this work funded in any way?

Tokio is a non-profit, community-supported project, although many of us work on it as part of our day jobs. If you want to support Tokio development, you can contribute to it on GitHub Sponsors (https://github.com/sponsors/tokio-rs) and on OpenCollective (https://opencollective.com/tokio).

I've also recently started accepting donations on my personal GitHub Sponsors page (https://github.com/sponsors/hawkw) if you're interested in supporting my open-source work in particular.

Perfect! Thanks.

Is there any question we should ask ? About some challenge or interesting discovery / aspect that most of us wouldn't even realise ?

Could you please go get hired by Apple and implement this for Swift? Pretty please!