Clojure core.async and Lamina

Question

Is core.async a replacement to Lamina or does it intend to become a replacement for Lamina?

If not, are there clear situations where one is preferable over the other?

Transport

The many flavors of concurrency in Clojure may be interesting - adambard.com/blog/clojure-concurrency-smorgasbord – Winstonwinstonn

I saw that and although it was a great article, it was a bit too 'nice' to answer my question I think. – Transport

Answer 1

I'm the author of Lamina. I think core.async is a well-made library, with a lot more clarity in its design than Lamina. There are things that I think Lamina is better at, mostly related to introspection, performance, and extensibility.

The big problem I have with core.async is that in addition to a stream abstraction, it brings along an execution model (everything happens on the core.async thread pools), which means that if you use it anywhere, it constrains the design and implementation of everything else in your codebase.

I've seen a number of "async" libraries made that expose streams as core.async channels, which means that you can only use the libraries if you're comfortable using the core.async execution model.

I'm about to release a library that tries to be a "minimal" stream representation that can be used in place of core.async, Lamina, Java blocking queues, etc. called Manifold. A Manifold stream can be coerced to a core.async channel, Lamina channel, and so on, and any of these things can be coerced back into a Manifold stream.

I think the "async" landscape is still quite young, and there are a lot of unexplored problems w.r.t. how well the abstractions scale, how easy they are to debug in production, and so on. The JVM provides a lot of tools for introspection, but since the async mechanisms use a complete different execution model we're basically starting over again from scratch. I wouldn't tell you to use Lamina over core.async, but I would caution that core.async is an application-level abstraction, not a library-level one.

Freeman

Thanks very much for this, always best to hear from the authors. I did not realise that about core.async and a good thing to consider. I will read the rationale document for Manifold, but it's a bit late on a friday now :) – Transport

Manifold looks good, certainly but I still need to make a choice behind it. It seems though that Lamina and core.async probably will both stay around as different strategies for the same end goal. I think I will play more with Lamina as it's already in our code base, however core.async did allow me to simply wrap something in a go block and see ma massive performance increase, without needing to change the way I think about that piece of code. – Transport

I see now that Lamina has been deprecated. I am using Manifold at the moment for a Kafka client, it seems a perfect fit because I can make a simple library that returns a stream and people can use it how they like, as a channel, a seq, a manifold stream etc. Great (assuming it works :) )! – Transport

Answer 2

core.async and Lamina are two different projects and they aren't intended to replace each other. Actually, they could play nicely together -if you want to-.
Lamina is a stream oriented approach, while core.async is message oriented.

Which one to use is up to you. In Lamina, the important thing is the callbacks you define for the channel, while in core.async, channels and go blocks are decoupled, and this is more flexible and modular.

Thorax

Ok, so I would imagine that the creators of core.async would think that it is a better way to do things than Lamina, no? – Transport

@Transport I don't know, better to ask them :) Given my answer, I didn't mean core.async is better than Lamina – Thorax

I said that as I had just watched Rich Hickey's talk about core.async ;) – Transport