Live data from Hacker News

Clojure Concurrency Tutorial

purelyfunctional.tv

11–20 of 43 posts

Re: Clojure Concurrency Tutorial

#11
post #8
post #5

Earlier quoted context omitted.

It is maintained, but not actively. Like the last year there was two issues fixed in it. There isn't someone actively trying to enhance it or add more features to it. So my understanding is only major issues gets addressed.

Which is a quite peculiar and reccurrent pattern in closure. After a while libraries and tools stabilize and the community just maintains it.

Most Clojure libraries I've worked with, even the "larger" ones, are fairly small and concise by modern standards. I wonder if this has something to do with the lack of activity (in addition to being a small community). It feels a bit like the Unix philosophy - lots of small/medium libraries handling discrete problems, rather than many competing mega-frameworks. To me, this feels like a silver lining that comes from the limitations of a smaller dev community.

Re: Clojure Concurrency Tutorial

#12
post #3
post #2

I get to do Clojure about ~60% of the time at work now, and it never ceases to amaze me how much easier it is to deal with concurrency than in vanilla Java. Futures and Promises and core.async don't allow you to totally avoid planning out your project (I've been bitten slightly by core.async's `go` blocks behaving differently than Go's goroutines), but they are a godsend compared to dealing with manual mutexes and se…

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.

Re: Clojure Concurrency Tutorial

#13
post #8

Earlier quoted context omitted.

Which is a quite peculiar and reccurrent pattern in closure. After a while libraries and tools stabilize and the community just maintains it.

Most Clojure libraries I've worked with, even the "larger" ones, are fairly small and concise by modern standards. I wonder if this has something to do with the lack of activity (in addition to being a small community). It feels a bit like the Unix philosophy - lots of small/medium libraries handling discrete problems, rather than many competing mega-frameworks. To me, this feels like a silver lining that comes from…

This is why I love functional programming as a whole. I feel like my code is really terse, without little/no sacrifices in expressivity, and usually no substantial sacrifice in performance.

Re: Clojure Concurrency Tutorial

#14
post #8
post #5

Earlier quoted context omitted.

It is maintained, but not actively. Like the last year there was two issues fixed in it. There isn't someone actively trying to enhance it or add more features to it. So my understanding is only major issues gets addressed.

Which is a quite peculiar and reccurrent pattern in closure. After a while libraries and tools stabilize and the community just maintains it.

To me, that sounds like a Good Thing.

Re: Clojure Concurrency Tutorial

#15
post #4
post #2

I get to do Clojure about ~60% of the time at work now, and it never ceases to amaze me how much easier it is to deal with concurrency than in vanilla Java. Futures and Promises and core.async don't allow you to totally avoid planning out your project (I've been bitten slightly by core.async's `go` blocks behaving differently than Go's goroutines), but they are a godsend compared to dealing with manual mutexes and se…

I was reading somewhere that the core.async lib has not been updated in awhile...is this correct? (generally curious if the lib is actively updated)

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

Re: Clojure Concurrency Tutorial

#16
post #15
post #4

Earlier quoted context omitted.

I was reading somewhere that the core.async lib has not been updated in awhile...is this correct? (generally curious if the lib is actively updated)

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.

Re: Clojure Concurrency Tutorial

#17
post #16
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, 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.

Re: Clojure Concurrency Tutorial

#18
post #17
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, 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.

Re: Clojure Concurrency Tutorial

#19
post #4
post #2

I get to do Clojure about ~60% of the time at work now, and it never ceases to amaze me how much easier it is to deal with concurrency than in vanilla Java. Futures and Promises and core.async don't allow you to totally avoid planning out your project (I've been bitten slightly by core.async's `go` blocks behaving differently than Go's goroutines), but they are a godsend compared to dealing with manual mutexes and se…

I was reading somewhere that the core.async lib has not been updated in awhile...is this correct? (generally curious if the lib is actively updated)

A common pedantic comment I hear many times from clojure devs its that (the few)libraries are complete, just work and don't need any updates.

Far from the truth IME.

Having said that, Clojure is my favorite programming language for writing "business" applications.

Re: Clojure Concurrency Tutorial

#20
post #18
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.

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 library; you can add any language feature you want due to the awesome macro system in Lisps. Even if they deleted the core library tomorrow, we could still build in literally any language construct we want as a library.

This is why Lisp is made of magic :)

Post reply on HN