Comment by j-pb | Hacker News Reader

Comment by j-pb | Hacker News Reader

I don't agree on a few points.

Global atoms provide a good way to confine state into a single place. In my applications they serve as a in-memory database while everything persistent is written to disk in the form of a log (kafka, file append, you name it).

Agents provide a good way to serialise events akin to a transactor. Not every problem requires the parallelism or the concurrency gained by smearing it out into a nondeterministic pile of communicating processes that is a nightmare to test. In those cases having determinism and centralised state is a godsend. I see them as the atoms bigger brother.

In cases where you need some concurrency or parallelism futures are fine. They provide a simpler interface and can even be canceled as first class citizens, unlike CSProcesses which potentially linger around indefinitely without having a first class handle to kill them or see their status.

Core.async is heavily overused. If your application doesn't contain a multitude of moving parts that all need to execute concurrently I wouldn't touch it with a ten feet pole. The go macro is a clojure to continuation passing style compiler, and don't get me wrong it's a marvel of engineering, but it's also a sausage machine that makes code impossible to debug. The fact that processes aren't first class citizens makes it impossible to build erlang style resilient systems, and creates tons of zombie processes when using figwheel. People immediately grab it when building cljs applications even though a log/queue would give them much more reliable performance guarantees, much better debug-ability and better tool compatibility. (Re-Frame for example ditched core.async for their own queue implementation.) (If somebody is sharing that sentiment and looking for a kafka style log for cljs, I wrote one and it's been used in production for a while :) https://gitlab.com/j-pb/franz)

Last but not least, transducers make it onto my list of things to avoid. I'm not sure if they or core.async are clojures million dollar mistake. They are incredibly complex, even brought the spawn of the devil, volatile, into the language. Just for a bit of speedup and core.async integration.

> Global atoms provide a good way to confine state into a single place.

I think it's simpler to pass state as an argument to your functions instead. That's less complex and easier to test.

> Last but not least, transducers make it onto my list of things to avoid... They are incredibly complex, even brought the spawn of the devil, volatile, into the language. Just for a bit of speedup and core.async integration.

Transducers are not just for performance and core.async. They're a hugely useful tool that allows the various collection functions to be applied to sources that are not easily seq-able.

For instance, say I have some source of events, and I can register a callback to receive events. With transducers I can still use all the standard collection functions, even though there isn't an obvious collection to use them on.

>> I think it's simpler to pass state as an argument to your functions instead. That's less complex and easier to test.

James,

I was wondering what is the best course of action ini one particular situation. I am using your excellent libraries to create an HTTP API that needs to have state. I usually have an init function and using the ring init feature (see below). How would you not have an atom that hold lets say the DB connection info for a function that renders a html page displaying the version of the database, accessing the dbinfo with @dbinfo (that was updated at the init). Would it be possible to pass in to this function the state? Is it any different if I am calling @dbinfo in the actual function that renders the page or the calling function (router, or app definition)?

:ring {:init myproject.core/init :destroy myproject.core/destroy :handler myproject.core/handler}

> I think it's simpler to pass state as an argument to your functions instead. That's less complex and easier to test.

I completely agree with that sentiment. But I prefer to execute those functions with swap! on my application state.

That way I can always inspect it in the repl during development and production. Which is not so easy when it's just bound in the local variable of some thread somewhere.

As for transducers, tbh I haven't encountered the use case you describe yet.

Agents are effectively atoms jammed next to an unbounded queue or unbounded thread pool, depending on whether you use `send` or `send-off`. In cases where you have enough contention to actually need formal serialization, you don't want either of those.

If you have low contention, use an atom. If you have high contention, use atoms and/or pieces of java.util.concurrent.

Fair points, but they are good to get started and can later be replaced with a proper log e.g. Kafka and a worker thread :)

If that's a "proper" replacement, then I think you want a queue, not an agent.

Like you said an agent is a atom with a queue bolted onto it when only using send. ;P

Btw I think your libraries did the job core.async tries to do a lot better :) and to this date I can't figure out why they didn't received the same amount of attention, so thanks for those!

What's so complex about transducers? (let [my-xf (comp (filter even?) (map inc))] (sequence my-xf [1 2 3 4 5])) => (3 5)

Yeah but now try implementing a custom state-full transducer.

State-full things are always more complex, and I'd say their use is also niche (for example, state-full transducers where you can really shoot yourself in the foot since they grow infinitely in memory).

Can you help me update this[0] code to use transducers?

[0] https://github.com/divs1210/difference-engine/blob/master/sr...

Reply on news.ycombinator.com