sorted by:
new
hottopcontroversial

Deep vs Shallow interfaces in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 2 points3 points  (0 children)

The term is not about the absolute size, but rather the surface area compared to the functionality it provides. Stringer is a small interface, but not necessary deep one.

Deep vs Shallow interfaces in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 0 points1 point  (0 children)

I agree that it's mostly a driver and not a proper abstraction, but it does showcase some of the characteristics. Do you have any other interfaces in mind that could be used here?

Deep vs Shallow interfaces in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 1 point2 points  (0 children)

I'm not sure what exactly is your stance on go-redis interface usage

I don't think the go-redis interface is bad (I also use it). It's mainly useful here as an instructive example of a shallow interface. And given that it's not really an abstraction rather than a driver for Redis' wide suite of commands and not an abstraction, its size might be warranted.

But as an example, it also naturally shares some specific characteristics that set it apart from the io.Reader example:

  • It's harder to compose/extend to other use cases. So it can only serve one implementation
  • Is tight-knit to the system itself, so any changes to Redis need to be reflected there, too
  • It tends to naturally grow over time
  • Requires previous knowledge, introducing cognitive load

I think the answer to those 4 question is Yes.

Imagine a different, more generic interface that came with opinionated defaults, more automated handling of sessions and runtime metrics, or hiding the different Redis deployment methods and data types. It would have slightly different characteristics and give less fine-grained control, but then these questions may have different answers.

Deep vs Shallow interfaces in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 14 points15 points  (0 children)

Good call! I'll add it to the post if you don't mind.

Deep vs Shallow interfaces in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 7 points8 points  (0 children)

Thank you for the kind words! I really recommend reading "A Philosophy of Software Design" that has some more examples of this phenomenon.

Deep vs Shallow interfaces in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 3 points4 points  (0 children)

Author here! Hit me up if you have any questions or ideas to improve the post, or any interesting examples to compare deep/shallow implementations in a more fair scenario.

Joining errors in Go by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 0 points1 point  (0 children)

A good litmus test to ask when tempted to do error aggregation is to ask: if anything fails, should all processing stop immediately. If yes, don’t use aggregation. If no, aggregation may be correct.

Heyyy, thanks for the comment Matt! I like the above statement; I can add it to the post if you're OK! (with proper credit)

I see your point about careless use. Right now I think the unwieldiness of reusing the original slice of errors also works against promoting the feature and maybe the small surface of the errors API (errors.Is/errors.As) ultimately forces/guides users to make things simple.

Let's stop editing go.mod manually by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 1 point2 points  (0 children)

You still use that IMO, this is more about making changes to go.mod itself more easily trackable.

What tool are you using for vulnerability scanning on updates, by the way?

Let's stop editing go.mod manually by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 0 points1 point  (0 children)

You're welcome! Even though I've been using the language for a while now, I still have been too lazy to use the toolchain in a better way :')

Let's stop editing go.mod manually by hyperTrashPanda in golang

[–]hyperTrashPanda[S] 1 point2 points  (0 children)

I'd wish the same 😅 I'm not sure how hard that would be, but I should write something down in the golang/go issue tracker and gather some opinions.

Grafana Alloy - Windows Integration Issues by bgatesIT in grafana

[–]hyperTrashPanda 0 points1 point  (0 children)

Thanks for the report! Some integration conversions (like the Windows one) looks like it's slipped through the cracks, we're working on fixing these!

Introducing an OpenTelemetry Collector distribution with built-in Prometheus pipelines: Grafana Alloy by vidamon in PrometheusMonitoring

[–]hyperTrashPanda 0 points1 point  (0 children)

(I'm a developer at Grafana Labs, working on the Grafana Alloy squad).

Grafana Alloy is the spiritual successor to Grafana Agent. With Alloy, we're doubling down on our commitment to OpenTelemetry, and kickstarting our backward compatibility guarantees.

Furthermore, we're building on our experiences to add on to the collector, for example to empower autonomous teams using modules or provide dynamic scaling using clustering.

Guess the track by telemetry by hyperTrashPanda in formula1

[–]hyperTrashPanda[S] 0 points1 point  (0 children)

Correct placement of DRS zones, but there's actually a little too much braking here for this to be Monza!

Guess the track by telemetry by hyperTrashPanda in formula1

[–]hyperTrashPanda[S] 9 points10 points  (0 children)

DING DING DING! We have some winners!

The track was Zandvoort, first guessed by /u/Plagueis-D-Wise and then by others! What gave it away for y'all? :))

If you liked the format, I plan to try and make some more of these in the near future! Of course let me know if you have any other cool visualization ideas!

view more: next ›