The 2011 State of Clojure Survey is Open | Hacker News Reader

The 2011 State of Clojure Survey is Open

cemerick.com

60 pointspepijndevos19 comments

I used Clojure for most of my work in 2010. This year, my biggest customer is a Java shop. As much as I like Clojure (great community!) I have to say that I have enjoyed Java's lack of sharp edges this year. Prediction: Clojure will be much bigger, dev market share, in a few years. It is a young language and needs a little more time to keep getting better re: exceptions, even better tools, etc.

One problem that Clojure really does have is that there are other fun/good languages available. Seriously, with Common Lisp, (J)Ruby, Scala, Python, and even Java, there is a lot of competition for developers' mindshare.

For me, the bottom line is that designing and writing software is hard work, and I want to use languages that I am happy using. I started programming in the mid-1960s (I was just a kid, I am not that old :-) and I keep doing it because I really enjoy it. Pick languages that make you happy.

> What has kept you from using Clojure more than you do now?

- Future staffing concerns

This can be killer for a startup.

Although I do very much enjoy clojure and its not any easier to find ruby hackers these days since the demand is so high.

You have to be willing to train. We adopted F# as a first-class language last year. The vast majority of our code is C#, but F# is used when it has an advantage. We don't need everyone to know it, but are willing to train our staff or new hires on it. We have a fairly big C/C++ codebase as well, that has the same constraints.

This has also been the #1 show-stopping concern when I tried to introduce Clojure at my workplace, a small financial services company aspiring to be "enterprise"-y.

> What has kept you from using Clojure more than you do now?

I don't need concurrent code. I let the Web server and database handle that.

edit: Clojure is one of those groupthink subjects on HN. Say anything negative about it and you're destined to get downvoted. I admire Rich Hickey. I read Stuart's book. I wrote some code in Clojure and I came to a conclusion: for me it was a waste of time. I heart Ruby and Nginx and databases that handle state for me. I guess that opinion isn't valued around these parts.

This has to be one of the biggest misconceptions about Clojure. Clojure is first and foremost about managing state - the concurrency benefits fall out of that. Most software could benefit from managed state.

EDIT: though I don't agree with your viewpoint (why limit state management to your db and webserver, don't you want the same guarantees for your app logic as well?), I did not downvote you.

I'm using Clojure at my company, and I love it. However, I regularly come back to this point in arguments with my other Clojure-loving friends.

Clojure is a wonderful way of managing state in a _single JVM_. I think it has totally cracked this problem, and its model is the model I want to see everywhere for managing concurrency in a single process.

My problem is that I feel it's solving a problem I don't really have. I'm not making desktop software, so I just don't care about using a single machine's cores safely and efficiently. While you claim most software could benefit from managed state, my assumption is that the majority of people looking at Clojure today are thinking of it for server software. The issues there immediately spread beyond a single process, and suddenly all the magic of Clojure stops being relevant. To scale my app I'm using multiple processes across multiple machines, and while I'd love something similar to the Clojure model to apply there, it just doesn't.

I feel like Clojure has popped up at an unfortunate time when desktop apps are only just thinking seriously about concurrency, but server apps have already moved beyond the model that works within a single JVM. So I really don't know what its sweet-spot is.

All that said, I should repeat that I love the language and have found it an exceedingly productive way to work on the JVM. I just wish it solved even bigger, cleverer problems than it already does. ;)

Your argument goes both ways. i.e. Erlang while fantastic for distributed concurrency isn't so hot when you need to solve each portion of the problem in the shortest amount of time possible on each machine in your cluster utilizing all the cores you have without having to write a boatload of code.

I don't think so. Clojure is about using more verbs and less nouns (that store state). It's designed to manage LESS state, if any at all.

Clojure is about simplicity. It helps you get to the point. It helps you eliminate unnecessary state, and when necessary, helps you manage the state that is.

"eliminate unnecesary state"

What is it you said that I didn't?

I agree. At work, I fill our Java codebase with 'final' keywords because it helps me make more assumptions about code I didn't write.

You're not alone with regard to Ruby. I was lucky enough to start using Clojure pre-1.0 at work. I come from a background where I've done a lot of functional programming. With Clojure, it was a joy to finally use a Lisp with well-designed conventions that I could actually get things done with.

However, I've since moved on to Ruby and learned a lot about its metaprogramming features. This is purely my opinion, but I get the impression that a lot of people who are smart enough to get Lisp, functional programming, and metaprogramming dismiss Ruby as being yet another OO language too soon, before getting to know it. On the contrary, I've found that the more I learn about Ruby, the more it grows on me, and the more similarities I see it has with Lisp.

I guess what I'm saying is, the reason I use Ruby is kind of like the reason I use a Mac, or why I tend to use languages with dynamic typing. There's no one killer feature that I can point to over the competition. In fact, there are a number of features that are hands-down superior in the other. I haven't quite figured out how to explain it to people coming from the other side, but for me, Ruby just hits the sweet-spot on so many levels. People talk about Macs being usable and even loved by grammas who know nothing about computers and hackers at the same time, audiences on complete opposite ends of the spectrum. Ruby is similar. On the one extreme, it's approachable to complete newbs. I know designers who would turn their nose up at the sight of code but were willing to learn the basics of Ruby to implement their designs. On the opposite extreme, it supports first-class continuations out of the box, which isn't even part of the Common Lisp standard. Also, a lot of times when I would've needed a macro in Lisp, I simply didn't in Ruby. And that's hard to explain... Sure I can do things with macros in Lisp that I can't in Ruby, but all other things being equal, wouldn't you choose the non-macro way over the macro way? (Sigh... I hear the flames starting.)

I'm not sure I agree with you about state, but it's true that with a web server and db, I've so rarely ever needed more concurrency features. Maybe this means Clojure is just not meant for people like me writing mostly web apps. But to play devil's advocate, maybe it's a good thing to let a piece of software designed specifically for handling concurrency -- handle the concurrency. Namely, a web server or database. This actually forces me in a good way to design my app up front to do any heavy processing asynchronously outside of a web request, which often means a queue, which often implies work divided into small pieces run concurrently by workers (separate processes, possibly on remote hardware, not just using an agent in another thread or relying on shared memory) which may die at any time without significant effect (a la Erlang). ...Again, maybe I'm just not in Clojure's target audience.

I use Ruby at work, I like Ruby and I like its metaprogramming facilities. However Ruby's features just doesn't cut the mustard when you want to build something like this, https://github.com/clojure/core.logic. I'm also working on implementing a fast state-of-the-art pattern matcher a la OCaml, https://github.com/swannodette/match.

These aren't small metaprogramming things - these are considerable useful language features reachable in Clojure that are not reachable with acceptable performance in the current crop of mainstream dynamic programming languages.

Fair enough. But if you want to start citing examples, I could say the same about Clojure. As far as I know, without JVM changes there's no way in Clojure to implement conditions and restarts in a way that allows you to handle thrown exceptions from code that doesn't know about conditions. OTOH this is just a library in Ruby. https://github.com/quix/cond

I don't want to get academic/knit-picky. I guess my point is even though living on the JVM definitely has some big advantages, it also has some drawbacks.

I'm not trying to knock Clojure. I think it's great. But this thread is about why you're not using it. So I'm just speaking to that.

[Edited to talk less about Ruby and more about Clojure.]

Cond looks a lot like the Clojure error-kit library:

    (deferror divide-by-zero
      {:msg "Division by zero})

    (defn divide [x y]
      (if (zero? y)
        (raise divide-by-zero)
        (/ x y)))

    (with-handler
      (divide 10 2)
      (divide 18 3)
      (divide 4 0)
      (divide 7 0)
      (handle divide-by-zero
        (continue-with 42)))

Admittedly this doesn't violate your general point; there are things like continuations that are hard to do with Clojure due to limitations the JVM. However, I tend to find there aren't many things Clojure can't do, and in general it seems more flexible and better designed than Ruby.

Uh, the same way that Ruby can't really help with C errors and C can't deal w/ Ruby errors, right?

I actually rarely use Clojure's concurrency primitives. For me, it's Clojure's immutability, homoiconicity and sensible namespacing that I really like.

Off topic, I've noticed that comments on HN are being downvoted a lot more often than they were, even when those comments are entirely legitimate. It's getting to be somewhat problematic.

I wrote that better tool support is important for widespread adoption. I think widespread adoption takes care of most of the other problems such as staffing concerns and flaky libraries.

Reply on news.ycombinator.com