I think all mentioned issues are related to the implementation of the user probes, not the pattern.
You mentioned an observation methods, but essentially they are absolutely the same as hooks, just inverted (with a bit less overhead on branching and hook call). E.g. your example with bytesReceived counter can be implemented with atomic operation and further export on demand by some other goroutine.
But it doesn't work well in Go by several reasons.
For example, you usually define interface not in the package where its implemented, but where its needed. Thus you must provide such wrappers in every place where some (subset) of the `Client`'s methods are used.
Another reason is that such thing rejects an ability to use your struct as is, without interfaces (and thus sometimes without heap allocation for your struct).
And, finally, if you want to adopt such approach in proprietary/internal software, where interfaces usually change more often than in libraries, you will change code in N places instead of 1 (in best case); where N is number of instrumentation methods you want to provide "as feature".
> Yes, because then the library developer can define all of the things that COULD be interesting, and leave it to the user of the library to decide WHAT to record (filters), and WHERE to record it (exporters).
I agree that this uppercase words can be called as somewhat purposes of the tracing API. I believe also that I was talking exactly about the same approach in the article.
But I can't get how sticking to one particular library will help here? In other words, I think it will just greatly reduce the usage options.
What Im saying is that you can leave the generic hooks in the library (as it described in the article and gtrace) and then let the user choose which library to use inside what hooks.
As a library developer, don't you need to define exactly the same trace points (hooks) in your code?
Am I understand it right, that you suggest instead of doing it in a generic way (any tracing method could be plugged in this way), to stick to one particular library?
Tracing term is kind of overloaded. In this article its used not as _distributed tracing_, but as _instrumenting_. E.g., Linux's trace points, or any other tools such dtrace, strace and so on. So it doesn't relate to systems design decisions.
Anyway how will you collect that counters inside your component (to be observed later on demand)?