Fork me on GitHub

hi, i have a query about pub/sub. what happens to any message if they are not subscribed by any of them. Will they accumulate in the pub channel and prevent further put! Is there a best practice for using pub/sub?


I think that it's a "global pattern" in clojure: if you will call a zero-arg function, example (UUID/randomUUID), or (async/chan), it's better to let it be a argument.

👌 8
Alex Miller (Clojure team)14:12:11

@pradyumna this is covered in the docstring for pub: “Items received when there are no matching subs get dropped.”


regarding returning a channel vs. passing one in, I've very often found myself returning channels when building async APIs. for example, those APIs look similar to Datomic Client's async API which do not provide (or need to provide, IMO) a way to pass a channel in:


Is it different when your API is a “source” of values (e.g. from some external system) versus a “middleware”?


one piece of guidance I've seen from the Go people is that a function should accept a channel as an argument if it is going to be putting an unbounded amount of data over the channel.


and I wasn't really able to find much discussion about it


In clojure another argument for this is (among others) is that you can create the input chan with an xform (or useful buffer etc)


maybe a way to think of it is, pass a channel in if you would otherwise be passing in a callback/observer. pass a channel out if you would be returning a promise/future.


I'm not sure if that's a very useful distinction though


I tend to allow passing one via an opts, set a sane default if it's not supplied


Yeah, many times channels are used to just return a single thing. I wonder if promise-chan is better served if you just want to model an async api?


For single val yes. I did that a few times with db clients


It's much more lightweight


And the fact takes return the same val can be handy


But even a promise-chan can take an xform, so it's still useful to let the user pass it as arg if possible imho