3 ms·

The main issue with using Clojure is that you are expected to build everything out yourself. A lot of dependencies tend to stop being maintained after a while.

The main issue with using Clojure is that you are expected to build everything out yourself. A lot of dependencies tend to stop being maintained after a while. Auth systems etc. are half-baked with 10 different implementations on GitHub. The newer shinier ones lack in features while the more featureful ones are from 3 years ago and have not seen a single update since. Now lisp people like to say "but...but.. backwards compatibility!" Sure that works for a lot of things but it goes out of the window when you need to prototype something quickly and your intern using Django/Rails has already built a MVP while you are still trying to sort out your dependencies story. Now you can always pull in Java libs, but then you will spend the rest of the week writing a wrapper for a very tiny subset of features that only you would use and the next person that comes along will have to do the same thing for the subset of features that they use. Using Clojure (other Lisps have it way worse than Clojure so they are not even worth mentioning in an enterprise context) is a bit like using an extremely new cutting edge language like Rust or Nim where there's no high quality libraries for anything except the lowest common denominator but without the massive community and support. Yes Node has its issues. But at the end of the day, you still need to get things shipped. Elegant code that would look at home in SICP is useless when money is on the line and you can't ship. Clojure et al. is very much NOT a "Move Fast and Ship" type of language. If it's for a game jam where no one's using Unity and everyone's doing OpenGL or one of those dinky little Lua game dev suites, sure go for it. If it's your company, use Go and get things into production first. Don't get me wrong, I love Clojure. There are a lot of smart people doing interesting things with it. It's probably the most advanced of all Lisps in terms of beginner-friendly tooling alone (shoutout to the Nightcode and Parinfer authors!) and it's Java interop is tremendously powerful in the right domain. Just that the ecosystem feels at times like Android 1.5 with its terrible fragmentation problems. The main corporate sponsor behind the language gives off apathetic vibes to community needs and the lack of featureful, maintained libraries is covered up under the guise of "Big frameworks bad! Elite programmers build their own!"

yogthos 8y ago
That's precisely the problem that Luminus [1] solves. It provides a batteries included template that follows best practices as well as documentation on how you would accomplish many common tasks. Making an app is quite straight forward, and all you need is Leiningen [2] and a JDK. For example, you could do: lein new luminus myapp +postgres +auth +swagger This will create an app using Postgres as the database with a Swagger UI set up out of the box. During development mode you'd run the app with: lein run Any changes you make in the source will be automatically reflected when you reload the page. You can also connect the editor to the REPL that gets started on port 7000 by default. You can package this app for production with: lein uberjar and you can run the resulting jar as: java -jar -Dconf=config.edn myapp.jar You really don't have to hand roll your app and go hunting for libraries unless that's something you want to do. [1] http://www.luminusweb.net/ http://www.luminusweb.net/ [2] https://leiningen.org/ https://leiningen.org/
Scarbutt 8y ago
The sweet spot for clojure is data oriented/data processing backend services (data engineering), where you can leverage stuff like kafka, spark, etc. You are going to get frustrated if you use it for common CRUD websites where the node.js/ruby/python ecosystem actually has quality libraries for all the common parts. In most cases I wouldn't trade node.js for clojure when writing front-end servers.
jwr 8y ago
> A lot of dependencies tend to stop being maintained after a while. [...] The newer shinier ones lack in features while the more featureful ones are from 3 years ago and have not seen a single update since. A lot of libraries are not updated because they do not need any updates. This is surprising to people coming from other languages, but is fairly common in the Clojure world. I use many libraries which haven't been touched in 3-5 years and it is fine: they don't need updates. > Auth systems etc. are half-baked with 10 different implementations on GitHub Here I would agree — authentication is a problematic area. I use buddy, which I had to integrate into my ring+sente app manually with quite a bit of pain. Friend has the wrong abstractions, IMHO, and does not get the job done.
didibus 8y ago
Don't write a wrapper when using a Java lib. Just use it directly. Now the next person coming in just has to use it, no need to understand the wrapper and extend it. Interop is a first class feature specifically for that reason. For the rest, I can only say that I don't understand the sentiment. It's true what you say about lots of Clojure libs, they were one off projects from someone and work has stopped on them. But I am able to move fast and ship with Clojure. For me, I can actually move faster with it. That's one of my main reasons for liking it so much. There's a Java lib for everything complex. And there's a quality Clojure lib for everything common. I've never not found what I needed. And in general, I don't need as many things because the core libs are so full featured. I'm not trying to deny your experience. It just makes me curious how my experience can be so different and almost opposite. That's why I've concluded that it's just not for everyone. It seems you are either a FPer or you aren't. And you are either a Lisper or you aren't. And with Clojure, you have to be both a Lisper and a FPer.
- sansnomme 8y ago
  It has less to do with FP or Lisp and more to do a lack of emphasis for rapid development and a significant impedance mismatch with the rest of the ecosystem. JVM interoperability works when the API is clean. It doesn't when obscure OOP features are used three layers deep and have to be mapped into Clojure which is more functional in nature.

yogthos 8y ago

That's precisely the problem that Luminus [1] solves. It provides a batteries included template that follows best practices as well as documentation on how you would accomplish many common tasks. Making an app is quite straight forward, and all you need is Leiningen [2] and a JDK. For example, you could do: lein new luminus myapp +postgres +auth +swagger This will create an app using Postgres as the database with a Swagger UI set up out of the box. During development mode you'd run the app with: lein run Any changes you make in the source will be automatically reflected when you reload the page. You can also connect the editor to the REPL that gets started on port 7000 by default. You can package this app for production with: lein uberjar and you can run the resulting jar as: java -jar -Dconf=config.edn myapp.jar You really don't have to hand roll your app and go hunting for libraries unless that's something you want to do. [1] http://www.luminusweb.net/ http://www.luminusweb.net/ [2] https://leiningen.org/ https://leiningen.org/

Scarbutt 8y ago

The sweet spot for clojure is data oriented/data processing backend services (data engineering), where you can leverage stuff like kafka, spark, etc. You are going to get frustrated if you use it for common CRUD websites where the node.js/ruby/python ecosystem actually has quality libraries for all the common parts. In most cases I wouldn't trade node.js for clojure when writing front-end servers.

jwr 8y ago

> A lot of dependencies tend to stop being maintained after a while. [...] The newer shinier ones lack in features while the more featureful ones are from 3 years ago and have not seen a single update since. A lot of libraries are not updated because they do not need any updates. This is surprising to people coming from other languages, but is fairly common in the Clojure world. I use many libraries which haven't been touched in 3-5 years and it is fine: they don't need updates. > Auth systems etc. are half-baked with 10 different implementations on GitHub Here I would agree — authentication is a problematic area. I use buddy, which I had to integrate into my ring+sente app manually with quite a bit of pain. Friend has the wrong abstractions, IMHO, and does not get the job done.

didibus 8y ago

Don't write a wrapper when using a Java lib. Just use it directly. Now the next person coming in just has to use it, no need to understand the wrapper and extend it. Interop is a first class feature specifically for that reason. For the rest, I can only say that I don't understand the sentiment. It's true what you say about lots of Clojure libs, they were one off projects from someone and work has stopped on them. But I am able to move fast and ship with Clojure. For me, I can actually move faster with it. That's one of my main reasons for liking it so much. There's a Java lib for everything complex. And there's a quality Clojure lib for everything common. I've never not found what I needed. And in general, I don't need as many things because the core libs are so full featured. I'm not trying to deny your experience. It just makes me curious how my experience can be so different and almost opposite. That's why I've concluded that it's just not for everyone. It seems you are either a FPer or you aren't. And you are either a Lisper or you aren't. And with Clojure, you have to be both a Lisper and a FPer.

sansnomme 8y ago
It has less to do with FP or Lisp and more to do a lack of emphasis for rapid development and a significant impedance mismatch with the rest of the ecosystem. JVM interoperability works when the API is clean. It doesn't when obscure OOP features are used three layers deep and have to be mapped into Clojure which is more functional in nature.