> (would probably do it in a few threads, sending messages between each other).

The problem is that I try to abstract these things away – in Java, I have a general framework, and just do

    var c = new ObservableCollection<Message>();
    var f = new AsyncObservableFilter<Message>();
    f.setSource(c);
    f.addFilter(new DayChangeMessageFilter());
    f.addFilter(new CollapseJoinLeaveMessageFilter());
    f.addFilter(new RemoveIgnoredMessagesFilter());
    var adapter = new ObservableAdapter<Message, MessageViewHolder>();
    adapter.setCollection(f.getResultCollection());

and then I can do

    c.add(new Message(new Date(), "cube2222", "Well, I don't see any problems with the logic part."));

And this works for any type – I can use the same code for observable collections of IRC networks, of channels, etc. And I do use them for that. And if I change the filters, it also does the minimum amount of work necessary to update the list, and not a single CPU cycle more.

I’m using it with over 11 different types in the Java version, and I’d have to maintain 11 identical, but with different types, versions in the Go version.

You can understand how much of a pain in the ass this is.

Oh, btw, this also abstracts away the entire thread handling, while still doing it in a reasonable way.

And the backing collection doesn’t have to be a normal ObservableCollection storing data in memory – I also have ones using SQLite as backend, or caches, and I have the ability to add listeners for scrolling up or down to load or unload data as well, if it’s not needed anymore.

In Go, I’d manually have to reify all these, and if I find a bug in one, I’d have to update all of the others, too.