I see your point that recording must be much cheaper than exporting, and I completely agree with it.
Anyway how will you collect that counters inside your component (to be observed later on demand)?
48 karma · joined July 10, 2017
Anyway how will you collect that counters inside your component (to be observed later on demand)?
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".
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.
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?