On: Three Months of Go, from a Haskeller’s perspective...

[cube2222]

Of course I can't say for 100% as I don't know your codebase. But I think you could easily do this with Message being an interface defining the common functionality of your messages (like, probably, render(), timestamp(), id()). Then you could just have you DayChangeFilter use the timestamp, joinleave do a type assertion, removeignored check for the id.

If the genericism for you is also abstracting away the source of the messages -> in Go you just usually abstract sources as io.Readers.

All filters can easily be an intermediate channel which only sends further proper messages. Or just write a filter(func (m Message) bool) function which abstracts that away.

Though I understand you may want to use your Reactive collections and streams, this isn't really a case for Go.

Have I understood your use-case correctly?

[kuschku → cube2222]

See, the problem is that "message" is only used in this one place.

In another place, I use there a type such as network, and the filters are entirely different ones.

In yet another place, I use even other types.

The types used there have nothing in common, nor do the filters.

[cube2222 → kuschku]

Ok sorry, I thought the unit of generic'ness you mean is the message. You're basically just talking about generic custom collections. Yeah, it is a thing you won't get in Go. And you'll have to write it every time again.

I'm usually just writing custom ones for each case, takes just a little bit more work. If I need more genericness, as I said, I use Java/Scala/F#

EDIT: In theory you can hack this all together using interface{}, but I wouldn't do that, it's a hack and ignores the type safety of the language.