4 ms·

Clojure is good for everything you'd use Java for. So pretty much anything that's going to be long running, like services, or big apps meant to be open for a wh

Clojure is good for everything you'd use Java for. So pretty much anything that's going to be long running, like services, or big apps meant to be open for a while. Yes, that fits the enterprise use case perfectly. A backend for any service oriented architecture, ETL jobs, data processing pipelines, backend for websites, rest/rpc/graphql services, client/server applications, big data analysis, machine learning, etc. Clojure is not good for quick scripts, use bash, python, perl, hy, clojurescript, etc. for that. Clojure is not good for low level code, like drivers, embedded systems, os, etc. Use rust, c, c++, D, etc. instead. Clojure isn't good for squeezing every ounce of power out of hardware, such as games, use C++, assembly, etc. for that. Clojure isn't good for mobile app development, use Java, swift, c#, objective-c, etc. for that. Clojure isn't good as an embedded scripting language, use LUA, python, javascript, tcl, scheme, etc. instead for that. Therefore Clojure competes mostly against Java, Scala, C#, F#, GO, NIM, Haskell, etc. Now as an astute reader, you've noticed how none of the competing languages I've listed are dynamic or of the lisp family. This makes Clojure unique in its space and the most controversial.

zurn 9y ago
I think Clojure fits well to quick scripts and exploraory programming, because of the rapid turnaround in interactive development. The finished tool, if compiled, will start fast enough (~1 second for hello world) even though it loses a bit to Python scripts. Clojure also lets you drop down to the most basic JVM primitives, like unboxed types and atomics/volatile, so you can do lower level stuff than in other dynamic languages. You can even follow the asm code generated by the JIT. Combined with macros and other DSL building capabilities, I'd say doing low level or performance oriented work can be pretty productive with Clojure. DSL building blocks and dynamic nature also make it a pretty good embedded scripting language. Many embedded systems are plenty powerful enough to run Clojure (or Python or Java), so it works there too.
- didibus 9y ago
  What you say is true, yet false. While you can use Clojure for script, or performance heavy tasks, or embedded systems, I think it's pretty obvious it's not the right tool for those, at least not yet. If you want to mess around with scripts, performance heavy tasks or embedded systems, sure you can use Clojure, but if you are serious about any of them, it wouldn't make sense. You'd turn to languages that are better suited.
  - zurn 9y ago
    I don't think you addressed any of the arguments here, so quite far from obvious...?
    - didibus 9y ago
      Ok, well, for scripts: - You mention sub second load times. Based on https://dev.clojure.org/display/design/Improving+Clojure+Start+Time https://dev.clojure.org/display/design/Improving+Clojure+Sta..., the surveyed timings are around 2 to 5 seconds, going to 60 seconds for some. That's a bit too much for scripts, you can live with it, but users are going to be annoyed about it for sure. - Another issue is the difficulty in starting them. You need to invoke java with a class path setup. So you can't have self executing scripts. You can use inlein, but that brings us to my third point. - The bigget issue is that Java and Clojure are not standard on any machine. While python and bash tend to be. To use Clojure for scripts require each machine to be imaged with java, Clojure and inlein setup. About performance and low level tasks. I'm not sure which of my use case you're specifically talking about. But an OS and drivers need to be compiled to specific hardware, so Clojure isn't an option for low level code like that. Now the JVM isn't performant enough for major games, you can't control memory yourself, or target specific CPU instructions. Finally, only a minority of embeded chips support running a JVM instance, I'm not sure I need to explain any further, if you work in embedded systems, it just doesn't make sense to restrict yourself only to the more powerful chip that can run an embedded JVM. P.S.: I love Clojure, I wish it was great at all these use cases, but it currently isn't, and I think we do the community a diservice to make people believe it is, because they'll try it, and have a subpar experience, leaving them feeling like Clojure isn't that great afterall. I'd rather people try it for what it's good at.
      - zurn 9y ago
        That survey is unrepresentative for scripting, since it's a survey of all Clojure applications. Scripting tends to be one-off, custom high level logic. I'm sure any Clojure user will tell you that short programs start fast enough for scripting - and for development, you are live-reloading in the REPL with 0 startup time. About deployment and distribution, I think the JVM story is much better than the competition (Python, Node, etc) - you can just package everything in a single .jar and you need only this along with the JVM. Embedded systems, like I wrote above, are hardly restricted to this kind of tiny chip. Embedded systems these days are frequently powerful enough to run Clojure. There's a big market for developing embedded solutions that value memory-safety, fast turnaround times and on-devices development ability along with access to JVM libs. To summarize, I still disagree that all these broad sectors would be weak for Clojure (like you argued in your original post). There are be smaller niches inside these sectors that Clojure is not well suited to (like operating systems, or low-powered embedded, or frequently executed end-user scripts that need sub-second startup times, or code inside operating system kernels) but this hardly excludes Clojure for all your listed broad application areas.
heftyfive 9y ago
I agreed with most of your comment, but not the end. I don't think Clojure competes with Go or Nim. And Clojure seems to be the antithesis of Haskell. Clojure competes with Java, Kotlin, Scala, and C# if you're on an MS platform. I used Clojure for pet projects for a while (it's a gorgeous language) but eventually went back to Python because I wanted something with: * easier interop with C/native libraries, * faster startup (though for scripts, [inlein](http://inlein.org/ http://inlein.org/) mitigates this issue) * no requirement of the JVM * better error messages / more help finding my bugs * smaller memory and cpu footprint Looked at some Schemes (Chicken), but couldn't stomach the car/cdr/dotted-pair stuff after having nice data structures like in Clojure, Python, et al. Not interested in ClojureScript, as I don't want JS underneath. Still prefer Clojure-the-language to Python-the-language, but here we are.
- idobai 9y ago
  Clojure doesn't competes with anything because almost nobody uses it. It's actually just an over-hyped script language used by script kiddies. There are so many drawbacks in that language but of course, zealotry fuels ignorance.
- didibus 9y ago
  Why wouldn't Clojure compete with go or nim? Go and Nim are both mostly used for backend services, long running processes deployed inside docker instances, etc. I agree it competes a little less then it does against Java, C#, et all. But it still does, in that there's overlap for what projects they'd be good candidate for.

zurn 9y ago

I think Clojure fits well to quick scripts and exploraory programming, because of the rapid turnaround in interactive development. The finished tool, if compiled, will start fast enough (~1 second for hello world) even though it loses a bit to Python scripts. Clojure also lets you drop down to the most basic JVM primitives, like unboxed types and atomics/volatile, so you can do lower level stuff than in other dynamic languages. You can even follow the asm code generated by the JIT. Combined with macros and other DSL building capabilities, I'd say doing low level or performance oriented work can be pretty productive with Clojure. DSL building blocks and dynamic nature also make it a pretty good embedded scripting language. Many embedded systems are plenty powerful enough to run Clojure (or Python or Java), so it works there too.

didibus 9y ago
What you say is true, yet false. While you can use Clojure for script, or performance heavy tasks, or embedded systems, I think it's pretty obvious it's not the right tool for those, at least not yet. If you want to mess around with scripts, performance heavy tasks or embedded systems, sure you can use Clojure, but if you are serious about any of them, it wouldn't make sense. You'd turn to languages that are better suited.
- zurn 9y ago
  I don't think you addressed any of the arguments here, so quite far from obvious...?
  - didibus 9y ago
    Ok, well, for scripts: - You mention sub second load times. Based on https://dev.clojure.org/display/design/Improving+Clojure+Start+Time https://dev.clojure.org/display/design/Improving+Clojure+Sta..., the surveyed timings are around 2 to 5 seconds, going to 60 seconds for some. That's a bit too much for scripts, you can live with it, but users are going to be annoyed about it for sure. - Another issue is the difficulty in starting them. You need to invoke java with a class path setup. So you can't have self executing scripts. You can use inlein, but that brings us to my third point. - The bigget issue is that Java and Clojure are not standard on any machine. While python and bash tend to be. To use Clojure for scripts require each machine to be imaged with java, Clojure and inlein setup. About performance and low level tasks. I'm not sure which of my use case you're specifically talking about. But an OS and drivers need to be compiled to specific hardware, so Clojure isn't an option for low level code like that. Now the JVM isn't performant enough for major games, you can't control memory yourself, or target specific CPU instructions. Finally, only a minority of embeded chips support running a JVM instance, I'm not sure I need to explain any further, if you work in embedded systems, it just doesn't make sense to restrict yourself only to the more powerful chip that can run an embedded JVM. P.S.: I love Clojure, I wish it was great at all these use cases, but it currently isn't, and I think we do the community a diservice to make people believe it is, because they'll try it, and have a subpar experience, leaving them feeling like Clojure isn't that great afterall. I'd rather people try it for what it's good at.
    - zurn 9y ago
      That survey is unrepresentative for scripting, since it's a survey of all Clojure applications. Scripting tends to be one-off, custom high level logic. I'm sure any Clojure user will tell you that short programs start fast enough for scripting - and for development, you are live-reloading in the REPL with 0 startup time. About deployment and distribution, I think the JVM story is much better than the competition (Python, Node, etc) - you can just package everything in a single .jar and you need only this along with the JVM. Embedded systems, like I wrote above, are hardly restricted to this kind of tiny chip. Embedded systems these days are frequently powerful enough to run Clojure. There's a big market for developing embedded solutions that value memory-safety, fast turnaround times and on-devices development ability along with access to JVM libs. To summarize, I still disagree that all these broad sectors would be weak for Clojure (like you argued in your original post). There are be smaller niches inside these sectors that Clojure is not well suited to (like operating systems, or low-powered embedded, or frequently executed end-user scripts that need sub-second startup times, or code inside operating system kernels) but this hardly excludes Clojure for all your listed broad application areas.

heftyfive 9y ago

I agreed with most of your comment, but not the end. I don't think Clojure competes with Go or Nim. And Clojure seems to be the antithesis of Haskell. Clojure competes with Java, Kotlin, Scala, and C# if you're on an MS platform. I used Clojure for pet projects for a while (it's a gorgeous language) but eventually went back to Python because I wanted something with: * easier interop with C/native libraries, * faster startup (though for scripts, [inlein](http://inlein.org/ http://inlein.org/) mitigates this issue) * no requirement of the JVM * better error messages / more help finding my bugs * smaller memory and cpu footprint Looked at some Schemes (Chicken), but couldn't stomach the car/cdr/dotted-pair stuff after having nice data structures like in Clojure, Python, et al. Not interested in ClojureScript, as I don't want JS underneath. Still prefer Clojure-the-language to Python-the-language, but here we are.

idobai 9y ago
Clojure doesn't competes with anything because almost nobody uses it. It's actually just an over-hyped script language used by script kiddies. There are so many drawbacks in that language but of course, zealotry fuels ignorance.
didibus 9y ago
Why wouldn't Clojure compete with go or nim? Go and Nim are both mostly used for backend services, long running processes deployed inside docker instances, etc. I agree it competes a little less then it does against Java, C#, et all. But it still does, in that there's overlap for what projects they'd be good candidate for.