Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A simple core.async job system in Clojure

blog.janetacarr.com

Post reply on HN
Print view View original

11–18 of 18 posts

Re: A simple core.async job system in Clojure

#11

Post by Waterluvian »

lkrubner wrote: post #3

I appreciate this emphasis on simplicity and I recommend it to others. I've seen trends in the other direction which I think are dangerous. I notice that as some companies adopted a microservices approach there was a tendency to allow in more technologies than necessary. "Premature polyglot programming" is a disease that afflicts certain startups. While any sufficiently big company will be polyglot, a small startup n…

This is what I think about most when looking at languages. “How painful would it be if I implemented the minimum now and wanted to add more capability later?”

Some languages make it very painful to not have a mostly complete design upfront and then you’re trapped adding complexity just in case.

Re: A simple core.async job system in Clojure

#12

Post by smrtinsert »

lkrubner wrote: post #3

I appreciate this emphasis on simplicity and I recommend it to others. I've seen trends in the other direction which I think are dangerous. I notice that as some companies adopted a microservices approach there was a tendency to allow in more technologies than necessary. "Premature polyglot programming" is a disease that afflicts certain startups. While any sufficiently big company will be polyglot, a small startup n…

100% agreed. Unfortunately overdoing it on complexity early on seems to lead to a loss of the faith in engineering decision making even after overengineering leadership is removed.

Re: A simple core.async job system in Clojure

#13

Post by mark_l_watson »

I appreciate Janet’s aversion to adding RabbitMQ to the system. I had to use RabbitMQ with Common Lisp a year ago and in was a pain.

It looks like Clojure has better RabbitMQ client options than Common Lisp, but still, very cool to build something on core.async and keep things cleaner and simpler.

Re: A simple core.async job system in Clojure

#14

Post by elwell »

tombert wrote: post #10

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…

> 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.

Re: A simple core.async job system in Clojure

#15

Post by tombert »

elwell wrote: post #14
tombert wrote: post #10

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…

> core.async was actually the "killer app" For Clojure Script , 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.

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.

Re: A simple core.async job system in Clojure

#16

Post by jwr »

Yes! core.async is a great tool and I've used it to solve a number of problems effectively. I'm very happy with what I get: reliable, predictable systems.

A real "whoa" moment comes when you realize you can also use core.async in ClojureScript :-)

Re: A simple core.async job system in Clojure

#18

Post by yayitswei »

elwell wrote: post #14
tombert wrote: post #10

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…

> core.async was actually the "killer app" For Clojure Script , 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.

Post reply on HN