Hacker News new | ask | show | jobs
by tombert 753 days ago
core.async was actually the "killer app" that sold Clojure to me. I've always liked Go's CSP-style concurrency, but I wanted a proper functional language to go with it. It turns out that Channels/Queues are just an insanely good abstraction for getting threads to talk to each other. The closest general-purpose library I've found that helps bring that to the rest of the world has been ZeroMQ, which is great but not as easy and nice to use as core.async.

That said, I really don't think RabbitMQ is so bad. The default docker configuration for it is fine for most cases you're likely to come across for all but the biggest applications, and I do think that having the ability to have jobs restart/requeued when a worker crashes out of the box is worth the tradeoffs for slightly increased complexity. I usually just use a single docker compose and glue everything together in one big ol' YAML.

Still, there's obvious value in avoiding dependencies, so it of course depends on the size and scope of your project. If you think you're going to end up distributing this over 100 nodes, something like RabbitMQ or ActiveMQ might be worth playing with, but if you're just doing relatively small (at you appear to be in this project), it's probably the correct choice to mimic whatever behavior you need with core.async.

1 comments

> core.async was actually the "killer app"

For ClojureScript, it was React. Immutable state / functional programming fits so nicely, and hiccup syntax (JSX as simple vectors) is the perfect declarative (yet transformable) DOM structure.

Want to put in a plug for Electric Clojure. More composable than React (mix server and client code in the same function!) and more performant. I've had a lot of fun using it over the past year, and it's IMHO the most transformative tech I've seen in web dev.

Wrt the original article, effect systems like missionary (which electric is based on) can be used to complement or replace queues, often resulting in simpler code.

Oh absolutely, no argument here at all.

I don't do a lot of frontend, but for anything that does involve frontend I kind of refuse to use anything but re-frame. It took a bit of dogma-acceptance, but once I did I really liked it for all the reasons you listed, and in particular that there's no special JSX crap, and instead just using vanilla vectors and symbols. This has the interesting advantage where you can generate your HTML logic without actually having to import the re-frame/re-agent logic, which can be useful if you want to decouple logic from rendering.

I haven't done any benchmarks, but I haven't noticed re-frame being slower than vanilla React, it seems to be a comparable speed, but as stated I don't do much frontend.