Rich Hickey's Keynote from the JVM Languages Summit (video) | Hacker News Reader

Rich Hickey's Keynote from the JVM Languages Summit (video)

infoq.com

68 pointssharksandwich21 comments

I admire Rich Hickey and Stuart Halloway and I've been reading the prag programmer book on Clojure, but I still haven't been able to wrap my head around why I should replace my preferred language - Ruby - with Clojure.

I understand that if I was building a database, or a traffic control system or something with lots of concurrency, it's useful.

But if I'm building a web app, the appserver and database handle the concurrency issues for me.

So I haven't quite understood why Clojure is so important.

Clojure is important because it's a Lisp that runs on the JVM and uses existing Java libraries. It has taken big steps to improve Lisp's accessibility.

Do you like Lisp? If you like Lisp, Clojure is its most pragmatic dialect. I personally enjoy the simple, consistent syntax and functional programming style that Ruby lacks.

Note that while Clojure was designed with concurrency in mind, it's also good at other things — like Ruby, it's a general purpose language. However, you're going to be more productive writing a web app with Ruby right now because there are no libraries for Clojure that are as robust as Rails. That may change as Clojure's ecosystem grows.

Its more a case of do you understand lisp, because it seems to me that few people who really understand it actually dislike it, while most people who don't understand it seem to dislike it (parentheses and prefix notation being the two things people seem to hate most). Its difficult to explain the benefits of Lisp to someone who doesn't already understand Lisp...

That's really going to depend on what your web app does. Simple CRUD work? Clojure may not give you much benefit over RoR (at least not until compojure or one of the other frameworks gets a lot more time put into it).

If part of what your web app does involves heavy duty data processing then it could be much more interesting. Flightcaster (Ruby or JRuby, I forget which) on Rails front end, Clojure doing all the hardcore machine learning data crunching on the back end.

Of course being a compiled language, odds are you can write faster code in clojure in at least comparable number of lines of code to ruby, with the speed of the jvm. So if you think your site will see much traffic that might be valuable to you as well.

    JRuby
    
    faster code in clojure ... with the speed of the jvm.

Something irks me about this argument :-)

JRuby seems quite slow though. Definitely not 'close to the JVM' like Clojure. Perhaps we could say it's the speed of the JVM versus the speed of the JVM with an elephant sitting on it ;)

Touche, though way more people use things other then the JVM for ruby from the sounds of what I see standing on the outside looking in.

I haven't seen a compelling reason to switch to clojure either. Despite some people trying to argue to the contrary, fair benchmarks that I've seen put clojure on average at least 10 times slower than Java in CPU performance, and Java itself is often 50% slower than C or more. Why bother parallelizing when you're already 10-15 times slower? CPU's aren't free to run! They have to be purchased, consume power, require maintenance, and are prone to failure.

Also, as far as productivity goes, I don't see clojure providing any significant short-term productivity gains over existing scripting languages like Python and Ruby. The use cases for macros beyond lazy evaluation appear few and far between in practice, and most of us get along fine in practice without persistent heterogeneous immutable data structures and lazy order evaluation.

So, unless you enjoy learning languages for fun or find yourself thinking more clearly using a functional approach, and there appear to be many people on this site who fit into one or both of the above categories, you are just fine sticking with Ruby.

I think that it is difficult to know what constitutes a 'fair benchmark' for Clojure. Are we talking unadorned Clojure, Clojure with type annotations, Clojure using Java structures, or Clojure calling Java code? Clojure calling Java is as fast as Java (obviously). And what if I had 60 cores as opposed to just 4 or 8? Parallel naive Clojure would then be 4 times faster than the Java version. The parallel clever version in Clojure would most likely be much faster. And barring a breakthrough in quantum computing, you will some day have 60+ CPUs in your desktop.

Most of the benchmarks that I have seen that were legitimately 10x the time of Java were using unadorned Clojure on Clojure data structures... of course it is slower, the machine is doing a lot more for you.

And it is well and good that this is the case, because the purpose of Clojure is not to make that tight loop really fast; it is to get the logic of your program correct and avoid a lot of the subtle bugs that can happen. Concurrency has many advantages above and beyond parallelism.

As far as getting along without macros and lazy evaluation and heterogeneous immutable data structures, I will say that for a long time we got along 'just fine' without garbage collection; but now it is a feature of a large subset of languages (to the extent that Google has now added it to C).

This link is fairly illuminating of clojure's performance: http://gnuvince.wordpress.com/2009/05/11/clojure-performance.... A guy writes some Java code, writes some clojure code, and notices that the clojure code is ridiculously slower, about 100 times or more, even slower than his Python implementation! After some serious profiling and help from the clojure mailing list he gets it down to 6 times as slow. What if he decided to try to optimize the Java code even further? He might be even be able to push the gap to 10x.

As far as all computers having 60 cores some day, if your clojure code is 10 times slower than my Java code, I only have to use 6 of my 60 cores to be as fast as your clojure program, which would be bringing my 60 core system to it's knees. It's not like you can't parallelize in Java! It's going to be decades indeed before a 5-10x reduction in performance doesn't matter because of ubiquitous core availability.

I think you are missing my main point. If the java code is faster, and you really need speed, just call the optimized java code.

If you take seriously the rule that most programs spend 90% of their cycles in a limited number of subroutines (and you rewrite those few locations in Java), you should get speed pretty much equivalent to the Java code.

(Of course, in benchmarks this fails, because benchmarks generally measure the places that i might rewrite).

And then you use Clojure for the tricky and error-prone flow control types of jobs. I hate it when people turn this into a 'Clojure vs. Java' debate. It isn't like that.

It is about Clojure and Java. And I think Clojure and Java wins hands down over the Java only approach (at least for a lot of applications).

Sorry if I started sounding like I was making this a Java vs. Clojure approach. I wasn't. My original point is that there are no compelling reasons for me to use a language like Clojure over a language like Ruby. Clojure's biggest selling point, having high-level primitives to parallelize with, is meaningless to me because it is so slow, and it's other selling point, increased productivity, doesn't doesn't mean much to me either because I feel like I can be just as productive in Ruby or Python. I can make those my glue languages. I was originally responding to a post by someone asking "Why Clojure over Ruby?"

By the way, I think combining multiple languages on the JVM is a great idea and it was what prompted me to investigate Clojure in the first place.

One of the amazing things in rails compared to many other frameworks is that the methods are all so forgiving, very neatly written multimethods: it doesn't matter if you enter a number,a string, an array or a hash, rails will be able to use the arguments properly.

With lisp/macros you can have similar power but with structure and logic.

Look at the difference between ERB templates and the beautiful templating language in compojure for example. It really kicks the llamas ass.

One of Clojure's nicest features is the seq abstraction, which lets you use almost all the data structures, from a String to a JDBC ResultSet, with a first/rest (aka car/cdr) interface.

It is hard to describe in a HN post why Clojure is a good idea.

Easy concurrency is a reason, certainly. You can build applications without having to worry too much about locks and such. You can utilize in language data structures for concurrency rather than worrying about a database handle (if you have, for example, data you don't need in a database, there is no reason to use one...)

Functional programming is another reason, programs are easier to reason about if you limit state to a few key places in the program.

Macros are a good reason too, instead of working around deficiencies in a language, just implement a macro. I used erlang Jinterface to implement an erlang-style message passing library last weekend. (With process spawning semantics and blocking receive, I haven't done pattern matching.. yet).

Java libraries are another reason to use it. You have full access to Java libraries like Jetty and Jinterface and others, and they pretty much blend into the language.

I have no idea about the relative merits of Ruby and do not wish to offer my reply as a challenge; 'i bet it can't do this or that'.

But Clojure certainly offers some interesting solutions to common problems in code (verbosity, clarity, libraries, concurrency, reliability).

I'm not very familiar with Clojure. On the first glance it looks like Clojure has a good concurrency system. I know many people are talking about Actors(like in Erlang) these days, but from my experience with Scala Actors, they're not very suitable to solve some problems(like when you need a very good performance). Even though Scala makes your life easier to work with native Java concurrency, it's definitely a good reason to have a deeper look at Clojure. Thanks for the info!

Edit: Is there an 'easy' way to create OSGi bundles with Clojure, maybe some sort of Maven plugin?

Clojure has a few different concurrency mechanisms. Agents are useful for asynchronous manipulation of mutable state while refs allow for coordinated synchronous changes. Atoms allow uncoordinated synchronous access to state while vars act as mutable storage locations on a per thread basis.

Between these, you get four different strategies for dealing with concurrency. Depending on your problem, you can choose the most efficient mechanism. Rather than shoehorning you into a particular strategy, Clojure gives a you a toolbox for dealing with concurrency and lets you chose what makes the most sense.

You forgot one: if, for some reason, none of the four mentioned concurrency strategies suit your needs, you can fall back to Javas monitor-based threading model. I don't see why one would want to, but I'm sure there are situations when this actually is the most appropriate mechanism.

And a possible future feature is something like statically-checked locking, where order-of-acquisition issues are dealt with.

Actors for Clojure has been mentioned as a future feature, but this would be for remote procs. Clojure has Agents for local async state changes, but these are only used when you need that feature, not ubiquitously. You should ask on on the mailing list - people have worked with osgi and maven.

A bit off-topic, but I've been seeing more infoq lately, and I'm wondering if there's a pwnyoutube/deturl type thing for infoq. I found the conclusion to Rich's talk on youtube, but it looked like it was filmed with a cell phone and it was only the last few minutes of the talk. Any pointers to a download link would be much appreciated.

Reply on news.ycombinator.com