One of little secret of Clojure is that you almost never use Java based library. Because it forces you not to use idiomatic Clojure. So, most library you'll use in Clojure are in fact Clojure made. From this point of view of number of libraries, Haskell and Clojure are in fact at the same level.
I was sold in part by the JVM argument. But in reality, in practice, I found it to be more a burden than a delight. First, the stack trace errors. To deploy your application, it is not just a "copy your jar in Tomcat". You have to serve using Clojure. So in reality, you don't get all advantages provided by the JVM environment, only some.
Clojure is fast, but, Haskell is at least as fast as Clojure.
Up until here, I had all packages I needed. There are all here[1]. I made mostly Web oriented programming, but using MongoDB worked extremely well for example.
And the most important aspect (from my experience):
When your program growth, in Clojure the time you spend to add another feature growth rapidly (it is better in clojure than most other languages thought), but in Haskell, each new feature doesn't cost so much, even in a medium to big project.
So when you need to change something fast without breaking something (the without breaking something is the important part), nothing beat the Haskell type system (or may be Idris, but I didn't played with it enough).
Furthermore, the ability to minimize the number of bugs, gives me a good feeling about the quality of the libraries. Of course, Haskell is not magic, you still have to pay attention to bugs, to test your code. But Haskell helps a lot in not falling into dumb bugs.
> One of little secret of Clojure is that you almost never use Java based library. Because it forces you not to use idiomatic Clojure. So, most library you'll use in Clojure are in fact Clojure made. From this point of view of number of libraries, Haskell and Clojure are in fact at the same level.
In a production server I'm running right now, I've used three java libs, wrapped them very nicely and neatly, and they work great.
> I was sold in part by the JVM argument. But in reality, in practice, I found it to be more a burden than a delight. First, the stack trace errors. To deploy your application, it is not just a "copy your jar in Tomcat". You have to serve using Clojure. So in reality, you don't get all advantages provided by the JVM environment, only some.
For my current app, I just need to do:
lein ring uberwar, copy to tomcat directory. done.
The rest I can't speak towards as I don't know Haskell. Also, it should be noted, I'm only offering counterpoints because I don't want people to not use clojure because of some of the incorrect claims. I guess we've had different experiences with clojure. :)
> One of little secret of Clojure is that you almost never use Java based library. Because it forces you not to use idiomatic Clojure. So, most library you'll use in Clojure are in fact Clojure made. From this point of view of number of libraries, Haskell and Clojure are in fact at the same level.
This isn't really true.
Yes, directly using a Java library forces you to use Clojure that is not idiomatic but 1) this isn't always the case 2) there are idiomatic wrappers over some libraries already.
More importantly, at least you have the option of using Java libraries. Having to use Clojure code that is not idiomatic still will be much more productive than writing the library yourself in Haskell.
Haskell does have a pretty good C FFI, so it's not as if you're necessarily going to have to reinvent the wheel. I know precisely nothing about Clojure's C FFI - I'd guess it has a fine one, which of course means that this isn't an edge for Haskell per se but it does make the Java interop slightly less important.
haskellnet looks like it does polling, but i gather its not quite the same thing. looks like you're right. I wonder how hard it would be to implement such a thing.
Clojure sits on top of the JVM, and as such, has the benefit of interop with some of the most robust software packages in the world.
Unless I'm missing something, you'd need to roll your own packages in Haskell for all this functionality.
I would argue that the most efficient code is well maintained open-sourced code that you don't have to write.
I don't use Haskell, so there may be lots of libraries I don't know about, so forgive me if this question is naive.