I've used almost this exact pattern (in Go) for a data normalization system. Considered sharing the code, but "never got around to it". What I built actually closely resembled node.js's streams.

Really convenient when you've got various chains of transformations that need to be combined/reordered/dropped while processing streams of data.

I am not reinventing the wheel here I have just tried to add a pattern I really like in other programming languages that I was missing in Go. You can use it however you want, and if you don't like it just use something else.

> Have you ever done that sort of thing before? yes I did that's one of the reasons I had to code go-observable

> I am not reinventing the wheel here...

I never said that you were. :)

> yes I did that's one of the reasons I had to code go-observable

I don't mean to sound mean or anything like this, but you do know that this question was directed directly at fiatjaf, and noone else, right? :) [0] I mean, I guess I appreciate the input, but I asked the question because it seemed obvious to me -because I spent several years working with software that made use of Pub/Sub mechanisms- that go-observable was a Pub/Sub mechanism for Go. So... I was wondering if fiatjaf had ever done any such thing in the past.

Obviously, as you are publishing a pub/sub mechanism in a given language it's either because you had need to do it in the past (or you were just doing it for funzies) and are sharing the fruits of your efforts. :)

[0] Or did my comment appear to be a direct descendent of your HN post, rather than a descendent of fiatjaf's question? I've heard that particular bug mentioned once or twice in the past.

Ok sorry I thought the question was referred to me :) There are many pub/sub modules for go but I made this one because I was missing in some case the asynchronous callbacks that I can use with other languages ( node for example ) but in a really simple way without too many ceremony (probably I am too stupid for other solutions) and also with the benefit of using the async go routines that IMHO are an advantage and not cons like someone else pointed out (performance tests are still needed here)

I was under the impression that this was useful only for GUI programming, but yes, that's a use case. I'm happy to know there are other legit use cases.

Oh yeah! Pub/sub is useful anywhere you have an N message producers and M message consumers (where both N and M are >= 0).

I mean, the way pretty much everyone does GUIs (with the central message pump that pulls external events off of a queue and changes UI state based on those messages) is an entirely reasonable way to think of all systems that use message passing to communicate -e.g. Elixir or Erlang- between loosely coupled parts of the system.