Comment by emidln | Hacker News Reader

Comment by emidln | Hacker News Reader

Parent Full thread

I use Clojure (or Clojurescript) for all of the things you listed. When I need something other than Clojure, that thing is typically C which is either a device driver or something I'm going to call into from Clojure. In the past I used mostly Python/Javascript/C instead of Clojure/C to get where I wanted to be.

Just to be clear, I use clj/cljs (day to day) for:

* Mobile Applications on Android/iOS

* Analytics and Data Wrangling off queues

* Data Analysis

* Admin Dashboard stuff (CRUD, Charts/Graphs, misc)

* Business Rules

* User Messaging (Push / Email / Webhooks)

* Database ETL

* Web Services

* Background jobs

* Build System and Deployments

The only thing I don't use that is Clojure-based, on a regular basis for my job, is SaltStack for configuration management (and this is largely because we have a working SaltStack system that I don't have a need to mess with).

I'm super happy when I can spend most of my day with a monitor dedicated to Spacemacs while jacked into a clojure repl.

But does Clojure/C really makes you more productive than Python/Javascript/C? which I guess is the point the GP was referring to, although, you mentioned it makes you happy (which is a good of enough reason as any).

Don't get me wrong, I think learning Clojure is helpful for lots of developers, even if they won't use it for work/side projects, and I think that's exactly what happens in the Clojure ecosystem and the reason for so many libs being half finished and abandoned, devs learn Clojure, grab all the ideas and concepts, scratch an itch but ultimate terminate going back to their mainstream langs.

It sounds like you're suggesting that Python/Node have better libraries, which couldn't be further from the truth. Most "abandoned" Clojure libraries either (a). aren't abandoned and "just work" due to their limited scope or (b). are wrappers to Java libraries that are trivial or unnecessary. Most people would rather to interop directly.

To offer one small piece of anecdote to the contrary: We use Clojure for most of our server-side code and picked Lacinia from Walmart Labs [0] to implement our new GraphQL API. It does most of the basics just fine, but its pace of development lags extremely, painfully far behind GraphQL server implementations in more popular languages such as the ones in Node and Python. To this day it still doesn't have support for custom directives [1], not to mention any of the other more bleeding edge developments in the GraphQL community such as schema stitching and live queries, all of which we would really have liked to experiment with along with the rest of the GraphQL community. We ran into similar issues initially when trying to use gRPC with Clojure.

We love writing Clojure and still use it everywhere where appropriate, but the size of its community and ecosystem is definitely holding back its ability to compete for adoption with other languages on the bleeding edge of new technological trends.

[0] http://lacinia.readthedocs.io/en/latest/

[1] http://lacinia.readthedocs.io/en/latest/directives.html

Fair -- GraphQL seems like something that is particularly well suited to having a Clojure API so that's disappointing to hear it lags behind other implementations.

To what extent does the Python GIL hold it back from performing multithreaded tasks as compared to Clojure? I'm mostly a Python programmer but I've experimented with Clojure a few times for some small projects, and I've noticed the multithreading options with Clojure to be more plentiful and capable.

Reply on news.ycombinator.com