Live data from Hacker News

Our experience using Clojure to speed up Beanstalk

blog.beanstalkapp.com

31–40 of 75 posts

Re: Our experience using Clojure to speed up Beanstalk

#31
post #28

Earlier quoted context omitted.

I think you are doing students and young programmers a disservice by implying that there is one "best" solution here, and that you know it. I am assuming you haven't seen the ruby or Clojure code involved, don't work at Beanstalk, don't know the skillset of their team, their budget, strategic plans, or any other one of a bunch of details that determine what is best in a particular situation. If you already know C the…

> I think you are doing students and young programmers a disservice by implying that there is one "best" solution here, and that you know it. I read their requirements in the blog post. They need fast access to SVN and Git internals to store off metadata. Based on that it's really not hard to determine what to use to solve this problem. There may not be one exact right answer (in fact, I suggested two), but there is…

I'm failing to see why Clojure is a bad choice for this problem. It's a general-purpose programming language, just like others that you mentioned. And beyond those, it happens to have the benefits of being more expressive, testable, concise, etc.

Can you elaborate on why you think it's a bad choice?

Re: Our experience using Clojure to speed up Beanstalk

#32
post #17

Earlier quoted context omitted.

Lines of code is the new form of premature optimization. A C solution is better in performance and compatibility, but you've prematurely optimized on lines of code as your deciding factor (based on you mentioning it in the article, and again here). Obviously, you can choose whatever you like, it's your company. I'm just explaining what the best solution was for the many students and young programmers who visit hacker…

Those same students and programmers should realize that yours is just one opinion among many. Your advice leans toward the "fungible cogs" school, where the capital crime is to expect others to learn something they don't already know. That's still a widely held view, and maybe even a majority, but probably not on HN. (see pg's Beating the Averages essay: http://www.paulgraham.com/avg.html )

> Your advice leans toward the "fungible cogs" school, where the capital crime is to expect others to learn something they don't already know.

Not following what you mean. Do you mean that I do expect people to learn stuff, or that I don't expect them to learn stuff in order to do their job?

Re: Our experience using Clojure to speed up Beanstalk

#33
post #10

http://shootout.alioth.debian.org/u64q/benchmark.php?test=al... Median speedup for the same problem in Clojure was 12x over Ruby. and 14x for Haskell; ... and 25x in Java .. and 35x in C++...

Alioth benchmarks are out of date as far as Clojure is concerned. These days it's not much work to get Clojure to deliver identical to Java performance. Better versions of the same benchmarks here that show the same performance as Java that you verify yourself - http://github.com/clojure/test.benchmark

>>out of date as far as Clojure is concerned<< What a pity that Clojure programs, written months ago to do benchmarks game tasks, have not been contributed to the benchmarks game for all to see!

Re: Our experience using Clojure to speed up Beanstalk

#34
post #30

Earlier quoted context omitted.

Alioth benchmarks are out of date as far as Clojure is concerned. These days it's not much work to get Clojure to deliver identical to Java performance. Better versions of the same benchmarks here that show the same performance as Java that you verify yourself - http://github.com/clojure/test.benchmark

"The Computer Language Benchmarks Game" has never been a valid benchmark for any language or implementation.

Why?

Re: Our experience using Clojure to speed up Beanstalk

#35
post #13

> I’ve been looking for an excuse to use Clojure in a production environment for a while Except in wanting to mess around with Clojure, you didn't use the best tool for the job. The Clojure solution now uses parallel implementations of Git and SVN to solve the problem, rather than the core code of SVN and Git. And now you also have a one-off daemon written in Clojure. It doesn't have the same support structure, ops r…

Grit doesn't use the "core code" of Git. GitHub found that using Git itself was too slow, so they wrote a parallel implementation of it in Ruby.

Re: Our experience using Clojure to speed up Beanstalk

#36
post #29
post #9

Earlier quoted context omitted.

Have you seen Leiningen[1]? It pretty much solves packaging and deploying problem. Awesome tool. Also if you're into Web development, I can recommend playing with Noir[2] framework and Korma[3] for SQL abstraction. Heroku also support deploying Clojure apps out of the box, so you can easily use a free tier to get something out there. [1] https://github.com/technomancy/leiningen [2] http://webnoir.org/ [3] http://sqlk…

I've got a question about Noir. Is it necessary for me to write HTML with Clojure, or can I separate it and write plain HTML somehow? Writing HTML in the middle of my Clojure code doesn't appeal to me coming from a MVC background...

Isn't that just the templating library (Hiccup iirc) that Noir defaults to? Check out Enlive, it's a nice alternative that addresses your concern:

https://github.com/cgrand/enlive

https://github.com/swannodette/enlive-tutorial/

Re: Our experience using Clojure to speed up Beanstalk

#37
post #34
post #30

Earlier quoted context omitted.

"The Computer Language Benchmarks Game" has never been a valid benchmark for any language or implementation.

Why?

Among others: because of completely arbitrary and I'd dare to say weird rules. Programs are not meant to be written in idiomatic language. They are meant to resemble the C implementation. In many cases you can see that the program representing the language in the comparison is neither the fastest nor the simplest of the submissions.

Re: Our experience using Clojure to speed up Beanstalk

#38
post #29
post #9

Earlier quoted context omitted.

Have you seen Leiningen[1]? It pretty much solves packaging and deploying problem. Awesome tool. Also if you're into Web development, I can recommend playing with Noir[2] framework and Korma[3] for SQL abstraction. Heroku also support deploying Clojure apps out of the box, so you can easily use a free tier to get something out there. [1] https://github.com/technomancy/leiningen [2] http://webnoir.org/ [3] http://sqlk…

I've got a question about Noir. Is it necessary for me to write HTML with Clojure, or can I separate it and write plain HTML somehow? Writing HTML in the middle of my Clojure code doesn't appeal to me coming from a MVC background...

Noir's indifferent to how you get your HTML; as long as you return a string, it'll serve it up:

    (defpage "/welcome" []
         "Hi there!")

Re: Our experience using Clojure to speed up Beanstalk

#39
post #37
post #34

Earlier quoted context omitted.

Why?

Among others: because of completely arbitrary and I'd dare to say weird rules. Programs are not meant to be written in idiomatic language. They are meant to resemble the C implementation. In many cases you can see that the program representing the language in the comparison is neither the fastest nor the simplest of the submissions.

You've made a bunch of claims without showing any evidence to support them. Please point to specific examples we can all look at on the website which show -- "Programs are not meant to be..." -- which show -- "They are meant to resemble the C implementation." etc

Re: Our experience using Clojure to speed up Beanstalk

#40

This is more about the Ruby VM being much slower than the JVM than anything to do with Clojure. It would be somewhat interesting to see how JRuby 1.7 running their Ruby code but using the Java libraries would fare.

JRuby is still going to be slower than clojure, due to the semantics of ruby. All function calls are resolved at runtime, while clojure resolves as many as possible at compile time.

Foo::Bar.method() vs (foo.bar/method)

The ruby version does three loads from the heap, at runtime, while clojure does zero.

invokedynamic in JDK 7 will help narrow the gap, but the fact remains that Clojure was designed with more performance in mind than ruby.

Post reply on HN