Eliza Weisman

@LucioFranco in your use-case, what are the motivations for rate-limiting? Is it intended to improve performance by eliding certain events, or just to reduce the noise of the logs for...

@LucioFranco have you done any benchmarking of your current rate-limiting implementation in vector vs not limiting events? The reason I bring this up is that if rate-limiting is intended for...

Some other thoughts: we've currently reserved the ability to add more complexity to `tracing_core::Interest` (note that `Interest::always()`, `Interest::sometimes()`, and `Interest::never()` are _functions_ rather than associated constants like `Level`'s "variants"), so...

> @hawkw I do have some basic benchmarks, generally, they show that a _very_ naive implementation doesn't add enough overhead that it will affect application performance. How I see it,...

It seems like there should be an assertion prior to the `next_power_of_two` call, in addition to the one after it?

I agree that it would probably be more correct to make stderr the default. We should probably change it. IMO, changing the default output stream is semver-breaking, so we would...

I think that in order to understand the difference between Loom and runtime checkers like Helgrind or TSAN, is worth noting that Loom is a model checker that _simulates_ the...

> This behavior might be intentional because the documentation for ConstPtr says that Loom doesn't track liveness. I'm not sure. I did not find an existing issue about this topic...

Mistakenly, I had thought that this already exists, but it turns out that I was actually thinking about [this impl](https://docs.rs/tracing-subscriber/latest/tracing_subscriber/fmt/trait.MakeWriter.html#impl-MakeWriter%3C'a%3E-for-Arc%3CW%3E). I think adding something like this makes perfect sense, as...

Thank you for working on this, this is great! I'll try to give it a review at some point soon, although I imagine @carllerche will want to as well.