Eliza Weisman

> I assume you mean that at `tokio::spawn`, if the user uses essentially `tokio::spawn(future.instrument(span))`, that span's user-set values would be worth including, which I agree. How would we detect that?...

cc @zaharidichev what do you think of this proposal?

Hmm, I do see why deltas are easier on the instrumentation side in cases like `RwLock`/`Mutex`, especially since the actual count is inside the semaphore and not exposed publicly. That...

One option might be to switch to a single field on the span, and use `Span::record`, but to special-case fields whose names end in `_delta`, and record `i64`s to indicate...

> I kind of think that having access to the span at every point in the code where you would want to fire a state update might require quite a...

> Where I am not entirely sure is the fact that the `value` of the attribute might be initialized in the case when we create the field with some known...

Oh, yeah, I hadn't thought about that. Hmm. We could just store the value as an `AtomicU64`, and then have an additional atomic metadata field that records what those bits...

This is definitely something I'd really like to see as well! The focus for the prototypes/MVP so far has been on inspecting the current state, since that's comparatively simple to...

I am also a big fan of the macOS Instruments UI --- it's one of the biggest things from the Mac that I miss on Linux. :) I was thinking...

My _guess_ is that this might be an upstream issue in the [`tui`](https://github.com/fdehau/tui-rs) crate, which we use for stuff like drawing the borders and layout and so on. It might...