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

Clojure Concurrency Tutorial

purelyfunctional.tv

Post reply on HN
Print view View original

21–30 of 43 posts

Re: Clojure Concurrency Tutorial

#21

Post by sbov »

tombert wrote: post #20
lukev wrote: post #18

Earlier quoted context omitted.

Clojure is far from perfect. But a lot of people are using it and will continue to use it effectively. It sounds like you're just salty for some reason. I'm sorry you had a bad experience, but that has no bearing on the usefulness of the language.

I don't want to speak for the original author here, but I believe he's basically saying that Clojure has a bit of a tradition of "change no behavior!". Rich Hickey has said as much in one of his talks [1], and while I think Rich Hickey is objectively smarter than me, I don't actually agree with him on this point. The difference between Clojure and nearly any other language, however, is that you don't need the core li…

But any language with any sort of traction has a bit of a tradition of changing no behavior, so Clojure isn't special here. So I'm not sure what exactly you disagree with here. It makes me think I don't quite understand what you actually intend to communicate.

Re: Clojure Concurrency Tutorial

#22

Post by tombert »

sbov wrote: post #21
tombert wrote: post #20

Earlier quoted context omitted.

I don't want to speak for the original author here, but I believe he's basically saying that Clojure has a bit of a tradition of "change no behavior!". Rich Hickey has said as much in one of his talks [1], and while I think Rich Hickey is objectively smarter than me, I don't actually agree with him on this point. The difference between Clojure and nearly any other language, however, is that you don't need the core li…

But any language with any sort of traction has a bit of a tradition of changing no behavior, so Clojure isn't special here. So I'm not sure what exactly you disagree with here. It makes me think I don't quite understand what you actually intend to communicate.

Back up, keep in mind that I'm not the same person as before, I don't disagree with you.

I think Clojure's built-in library is great, and more than production-ready. Not entirely sure what the parent was talking about.

Re: Clojure Concurrency Tutorial

#23

Post by ambulancechaser »

lukev wrote: post #16
thom wrote: post #15

Earlier quoted context omitted.

Yes. You should consider core Clojure (including everything covered in this article) as a proof of concept that will never be revisited.

Wow. That will come as quite a surprise to the dozens of Fortune 50 companies out there using it as part of their core systems, let alone all the smaller companies and startups. Source: Worked as a consultant almost exclusively in Clojure for the past 10 years.

I read that message to mean clojure/core.[library] and not clojure.core. It's a criticism of the slower development pace and low visibility that libraries like match, logic, combinatorics, test.check, data.zip, rrb-vector, cache, etc. have.

The author can clarify but if that's the critique its not without at least some merit.

Re: Clojure Concurrency Tutorial

#24

Post by thom »

tombert wrote: post #20
lukev wrote: post #18

Earlier quoted context omitted.

Clojure is far from perfect. But a lot of people are using it and will continue to use it effectively. It sounds like you're just salty for some reason. I'm sorry you had a bad experience, but that has no bearing on the usefulness of the language.

I don't want to speak for the original author here, but I believe he's basically saying that Clojure has a bit of a tradition of "change no behavior!". Rich Hickey has said as much in one of his talks [1], and while I think Rich Hickey is objectively smarter than me, I don't actually agree with him on this point. The difference between Clojure and nearly any other language, however, is that you don't need the core li…

No, this wasn't my point. I don't lament them not making breaking changes, obviously. My point was that most of the work the core team does is on projects that they will never revisit in the future. The one exception to this is spec, which drags on. Once it's out of alpha I expect them never to touch it again.

If you believe everything in core is perfect and fully formed, and that all other needs are served by libraries that are actively maintained, that's great. Not my experience by a long shot, but I'm happy to be grumpy in a world full of happy Clojure programmers.

Re: Clojure Concurrency Tutorial

#25

Post by thom »

lukev wrote: post #18
thom wrote: post #17

Earlier quoted context omitted.

I, too, have used Clojure as my primary language across three startups and 10 years, and despite my great affection for the language and community, I have told no lies here.

Clojure is far from perfect. But a lot of people are using it and will continue to use it effectively. It sounds like you're just salty for some reason. I'm sorry you had a bad experience, but that has no bearing on the usefulness of the language.

Nothing I said has anything to do with the usefulness of the language - I work with it every day and have for a decade, and I hope that I'm not completely crazy. I was just stating that anything that appears in core basically gets to 1.0ish and is never touched again. This seems demonstrably true to me, and not even necessarily a bad thing, but perhaps others disagree.

Re: Clojure Concurrency Tutorial

#26

Post by thom »

ambulancechaser wrote: post #23
lukev wrote: post #16

Earlier quoted context omitted.

Wow. That will come as quite a surprise to the dozens of Fortune 50 companies out there using it as part of their core systems, let alone all the smaller companies and startups. Source: Worked as a consultant almost exclusively in Clojure for the past 10 years.

I read that message to mean clojure/core.[library] and not clojure.core. It's a criticism of the slower development pace and low visibility that libraries like match, logic, combinatorics, test.check, data.zip, rrb-vector, cache, etc. have. The author can clarify but if that's the critique its not without at least some merit.

Yes, this is part of it (although I do include things like core.async, reducers/transducers etc in that). A lot of Clojure feels like a bunch of thesis projects tacked together and abandoned. Most of it was quite innovative and cool at the time, but it's not being iterated or elaborated on. That's nobody's problem, really, I just happen to find it frustrating.

I'd almost be encouraged by the rework going into spec if it wasn't happening at such a glacial pace.

Re: Clojure Concurrency Tutorial

#28

Post by chongli »

tombert wrote: post #7
quadcore wrote: post #3

Earlier quoted context omitted.

What's the difference between core.async go blocks and goroutine please, I thought they would be the same to a reasonable extent?

To a reasonable extent, yes, they're the same. The biggest issue is that goroutines are (more or less) fully preemptive (for all intents and purpose) with their thread pooling and go blocks in core.async are not. Basically, in Go, you can have as many blocking IO thing taking millions of seconds to run, but it won't block the thread pool, and your other goroutines will run fine. Since core.async go blocks aren't full…

What's the advantage of downloading multiple massive files in parallel, assuming you can saturate the link with just one? Isn't it better to finish one file before moving on to the next?

If you can't saturate the link with one file, then you should consider something like bit torrent.

Re: Clojure Concurrency Tutorial

#29

Post by jwr »

tombert wrote: post #7
quadcore wrote: post #3

Earlier quoted context omitted.

What's the difference between core.async go blocks and goroutine please, I thought they would be the same to a reasonable extent?

To a reasonable extent, yes, they're the same. The biggest issue is that goroutines are (more or less) fully preemptive (for all intents and purpose) with their thread pooling and go blocks in core.async are not. Basically, in Go, you can have as many blocking IO thing taking millions of seconds to run, but it won't block the thread pool, and your other goroutines will run fine. Since core.async go blocks aren't full…

This is true, but I think it's worth mentioning that core.async lets you freely mix "full threads" with work scheduled from a thread pool. You use the same channels for both. You do the lightweight stuff in go blocks, and the I/O heavy work in a `(thread)`, where you use `!!` for blocking gets and puts, respectively.

I find this to be amazingly flexible. You are right in saying that it's a gotcha: you do not want to do I/O heavy work in go blocks in general.

It is also worth noting that core.async works just as well in ClojureScript, which when you thing of it is pretty amazing. No threads there, of course.

Re: Clojure Concurrency Tutorial

#30

Post by jwr »

Blackthorn wrote: post #12
quadcore wrote: post #3

Earlier quoted context omitted.

What's the difference between core.async go blocks and goroutine please, I thought they would be the same to a reasonable extent?

core.async is a macro. Call an already compiled function under a library that blocks and the whole system will come to a screeching halt. Goroutines don't have that limitation.

Please see my other comment about using the same channels and calling I/O-heavy (blocking) functions from a `(thread)` instead of from a go block. You indeed shouldn't call blocking functions from go blocks, but core.async gives you the option of freely mixing separate threads and go blocks.
Post reply on HN