sdd commented on issue #482: URL: https://github.com/apache/iceberg-rust/issues/482#issuecomment-2760683598
I've looked into `fastrace` a bit more after our conversations about it yesterday and I must admit I have serious reservations about it. The benchmarks as reported by `fastrace` have been pointed out by `tracing` maintainers as being somewhat misleading as they are not comparing like-for-like. Whilst `fastrace` does still come out faster, it is nowhere near the difference claimed when a like-for-like comparison is made. Reference: https://www.reddit.com/r/rust/comments/1jh2fzg/fastrace_a_modern_approach_to_distributed_tracing/ In the blog post, the author makes claims about ecosystem fragmentation. I don't see how this is solved by introducing another tracing library. `tracing` is able to integrate with `log` already simply by enabling the `log` feature of tracing within our library. This is something that would be straightforward for consumers to do, and is also pretty common within the ecosystem already. So, someone who already has an application that is using `tracing` for tracing and logging is able to record logs from libraries that use `tracing` or `log`. But, they would have no recourse if they wanted to capture logs from a library using `fastrace` because there is no similar means of exporting `fastrace` logs / traces to `tracing`. This seems to make fragmentation worse, not better. The blog post claims that: > With tokio-rs/tracing, there’s no clean way to have tracing zero-cost disabled. This makes library authors reluctant to add instrumentation to performance-sensitive code paths. But it is trivial to do this in `tracing` too: https://docs.rs/tracing/latest/tracing/level_filters/index.html#compile-time-filters On context propagation, the blog post also claims that: > tokio-rs/tracing leaves this largely as an exercise for the developer. The blogpost seems to be deliberately misleading on this. It is pretty trivial to do this in the tracing ecosystem. In a real-life service you can do this trivially in one line of code by using libraries like [tonic-tracing-opentelemetry](https://docs.rs/tonic-tracing-opentelemetry/latest/tonic_tracing_opentelemetry/index.html) for gRPC services in Tonic or [axum-tracing-opentelemetry](https://docs.rs/axum-tracing-opentelemetry/latest/axum_tracing_opentelemetry/) for HTTP services in Axum. In fact this is the exact same approach that fastrace has also used, with the fastrace-tonic and fastrace-axum crates being separate. On the whole, the only claim in the blog that really holds up to scrutiny is that `fastrace` performs better. But even that has been exaggerated, can be mitigated, and in my real-world experience with using `tracing` with `iceberg-rust` already, is not significant enough to notice. Conversely, `tracing` has: * A much wider ecosystem (see https://docs.rs/tracing/latest/tracing/#related-crates) * much greater configurability * 10x as many GitHub stars * 50x as many daily downloads (it gets downloaded more times in one day as fastrace has in its entire history). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@iceberg.apache.org For additional commands, e-mail: issues-h...@iceberg.apache.org
