gobwas

Congrats on launch (if it is it actually). It reminds me of https://pace.dev, which was the same lovely idea which, however, I haven't heard of much after it was acquired. Have you compared your product with similar products and why yours is better? :) Thanks!

Thanks a bunch! Please reach out with any questions you have.

Thanks, more than happy to answer questions if you have any! It's a production service, not a PoC. It has been running under a synthetic load from three different locations for a ~month, which helped with many bumps and bugs.

Hey, thanks! Feel free to reach out if you have any questions!

I am wondering if there is a site with a perf/efficiency chart of the models over time? I am wondering is the pace still speeding up?

Thanks! Got my old-skulls cramped.

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)?

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.

Thats true that such approach also exists.

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".

Ah, cool! Thank you so much, didn't know about this parameter :D Will try it definitely.

I have read this article before and I really like the idea of doing so. I would love to read more about how you guys modified the compiler!

> 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.

<joke>Why has no one mention Go yet?</joke>