The appeal of Clojure decreases somewhat if one doesn’t care about concurrency. Its diverse and simple approaches to concurrency is one of its strongest selling points.
This is not aimed at the OP: not taking concurrency seriously, as a language, in this day an age, is disingenuous. You will not see a language become popular or be worth investigating if it doesn’t do so.
Of course I’d recommend the OP do the same, since concurrent programming is fun!
Clojure’s concurrency primitives get a lot of air time, but in reality: most Clojure programmers will never have a need to use a ref (i.e. software transactional memory). The “epochal time model” is massively useful even in single-threaded programs and the fact is that Clojure makes concurrency less painful by making sequentially programming simpler.
Clojure’s concurrency primitives get a lot of air time, but in reality: most Clojure programmers will never have a need to use a ref (i.e. software transactional memory)
That’s a bit unfair. I don’t think your second sentence logically follows the last. STM is but one part of the wide array of different concurrency primitives in the language, most of them a lot simpler than STM, and some of them quite ~~complicated~~ advanced (e.g. reducers and transducers). I know I’m splitting hairs a bit, I do agree with the latter part of your statement, though I would reword it as “by making programming simpler”.
Did you consider Scala? I’ve found it very Python-like, it has all the positives you list here (except perhaps a unified philosophy - I still think there is one but it’s much subtler than your examples).
A note on downvotes. I found this comment downvoted. It looked like it was downvoted for no reason other than the voter disagreed with this statement. As a community we wish to not have this negative culture. If you disagree with the comment, please write another comment, don’t try to railroad the original poster. Downvotes should be restricted to genuinely unhelpful content, like spam, trivial (e.g. “Me too”, “first post”) statements etc. Thanks.
I briefly reviewed it a couple years ago and wasn’t very charmed by it. Maybe I should give it another try.
Lack of a unified philosophy is what makes Scala completely unlike Python. I’d argue it’s the one thing that matters most.
Does Python have a unified philosophy? It certainly doesn’t in terms of object-oriented vs functional - it supports both approaches and it’s normal to use both in the same project, very much like Scala.
To me Python’s philosophy is that expressed in the zen of Python (simple is better than complex, explicit is better than implicit, there should be preferably one way to do a given task, readability counts, etc.). It may sound like obvious stuff, but most languages fail to apply it, and it certainly affects the way you decide how to design your code.
In terms of it being object vs functional, everything in python is an object (including functions), and in that regard Python is more object oriented than say Java. Now, from my point of view, being forced to put everything inside a class, not being able to use a function where a function will do the job, that would be the language getting in the way.
I think that Python philosophy does exist, but it’s certainly subtle; Python is a broad church and data-science Python looks very different from webapp Python which looks very different from sysadmin Python. I think Scala and Python are very similar in this regard.