Hacker News: gobwas

New comment by gobwas in "GPT-6.1 Terra"

gobwas — Mon, 26 Oct 2026 19:57:08 +0000

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?

New comment by gobwas in "Show HN: TitleArt – Make text like it's 1997"

gobwas — Mon, 26 Oct 2026 14:11:37 +0000

Thanks! Got my old-skulls cramped.

Gobwas/glob: a complete engine rewrite and v1.0.0 is finally here

gobwas — Fri, 28 Aug 2026 17:00:25 +0000

Article URL: https://github.com/gobwas/glob

Comments URL: https://news.ycombinator.com/item?id=49481431

Points: 2

# Comments: 0

Generic Concurrency in Go

gobwas — Fri, 17 May 2024 17:44:29 +0000

Article URL: https://sergey.kamardin.org/articles/generic-concurrency-in-go/

Comments URL: https://news.ycombinator.com/item?id=40392419

Points: 3

# Comments: 0

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 17:35:53 +0000

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

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 16:26:46 +0000

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.

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 14:08:26 +0000

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

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 13:11:32 +0000

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

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 12:21:16 +0000

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!

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 11:30:24 +0000

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

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 10:40:17 +0000

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?

New comment by gobwas in "Instrumentation in Go"

gobwas — Tue, 26 May 2020 09:44:19 +0000

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.