Clojurians Log v2

Thanks 🙌 . The gist at the #core-async https://clojurians.slack.com/archives/C05423W6H/p1737016774029119 is very helpful. @leif.eric.fredheim would it make sense to discuss a toy use-case of the kind you had in mind and explore together?

Can you elaborate a bit why you think it's a game changer? (haven't looked at that module yet)

(I see Rich added a https://github.com/clojure/core.async/blob/master/doc/flow.md doc in that reddit https://old.reddit.com/r/Clojure/comments/1i27n1k/rich_introduces_new_namespace_in_coreasync_flow/)

Lovely to see this

@gentkr: I worked for the largest electronics retailer in the Nordics in their Insights & Analytics department. As the Data Science Lead, I tried to "sell" Clojure to the Data Engineering team, which consisted of individuals primarily working with visual DAG/ETL/ELT tools, such as Airflow, Matillion, dbt, etc. I struggled to show/convince them how Clojure could offer greater flexibility and lower maintenance costs without vendor lock-in due to proprietary data formats, etc. Mainly because one would have to implement many "lower level things" using core.async and other libraries to achieve the same goals of moving, munging, analyzing, and visualizing large data sets. It looks like flow will simplify implementing DAGs using Clojure for users who are not necessarily "software engineers" and are not comfortable implementing systems using code. Defining DAGs as data is a lot closer to their way of doing things, making it easier for "enterprise data engineers" to adopt Clojure for their use cases. With flow, it would have been easier for me to convince them to try Clojure.

One of the main criticisms of core.async is that it is low level and doesn't provide lifecycle management or error handling. So this could be useful for..lots of people.

there's a thread on flow I'm watching in #core-async