3 ms·

Yeah maybe in general but what about a comparison for heavy IO applications? core.async vs node's system? I really hope Clojure catches on. It's so fun to writ

by ninetax 13y ago

Yeah maybe in general but what about a comparison for heavy IO applications? core.async vs node's system? I really hope Clojure catches on. It's so fun to write in, I'm never going back!

deleted 13y ago
[deleted]
film42 13y ago
Real quick: I wrote a little json-in-json-out app for working on webapps before the backend is done (first node (express)). Then, later rewrote it in clojure (compojure). They're both on heroku and perform about the same. This is by no means a real benchmark, but does show that node can keep up with the JVM for ridiculously simple apps. Node version: http://json-mirror.herokuapp.com/ http://json-mirror.herokuapp.com/ Clojure version: http://mirror-clojure.herokuapp.com/ http://mirror-clojure.herokuapp.com/ Also, ClojureScript is super interesting because a lot of clojure libraries will work (provided they're not a Java wrapper library) automatically. Draw backs though? Speed. ClojureScript uses Google Closure to optimize, which brings it close to pure JS speeds, but according to Conrad Barski, the webfui creator, it's not quite there. Check out his presentation though here if you're interested (demos and speed explanations included): http://www.youtube.com/watch?v=HeI5-D7SQe8 http://www.youtube.com/watch?v=HeI5-D7SQe8 CRAP: Should have replied to parent comment, but it's fine here as well.
- ninetax 13y ago
  Thanks! I'll take a look!
graue 13y ago
I'm not aware of a good reason to prefer ClojureScript+Node.js in general. Maybe if you wanted interop with a specific Node library, but otherwise, Clojure on the JVM will tend to have vastly better performance, and the tooling is better. For example, until recently ClojureScript's :keywords were just strings under the hood and it required a string compare to test equality. Apparently this is no longer the case due to this commit 2 months ago: https://github.com/clojure/clojurescript/commit/2cef52840fcd9d88f077d374cc81e50c7e645b9f https://github.com/clojure/clojurescript/commit/2cef52840fcd... but it shows you the kind of stuff you might run into. In a recent talk I saw by David Nolen, the lead maintainer of the ClojureScript compiler, he brought up multimethod dispatch as something that can still be as much as 100 times slower than the JVM. As a tooling example, Clojure gives you helpful errors if you initialize records the wrong way: user=> (defrecord Thing [foo bar]) user.Thing user=> (Thing. 1 2) ; correct usage #user.Thing{:foo 1, :bar 2} user=> (Thing. 1) ; wrong number of fields CompilerException java.lang.IllegalArgumentException: No matching ctor found for class user.Thing, compiling:(/tmp/form-init7089728177345913731.clj:1:1) user=> (Thing 1 2) ; forgetting the dot RuntimeException Expecting var, but Thing is mapped to class user.Thing clojure.lang.Util.runtimeException (Util.java:219) That's good! Especially if you're new to the language. You see where you messed up right away. But ClojureScript just silently gives you nils: ClojureScript:cljs.user> (defrecord Thing [foo bar]) cljs.user/Thing ClojureScript:cljs.user> (Thing. 1 2) ; correct usage #cljs.user.Thing{:foo 1, :bar 2} ClojureScript:cljs.user> (Thing. 1) ; wrong number of fields #cljs.user.Thing{:foo 1, :bar nil} ClojureScript:cljs.user> (Thing 1 2) ; forgetting the dot nil This should be a bug report against the CLJS compiler (edit: now it is[1]), and it's probably not that hard to fix. I could fix it. You could fix it. (The CLJS compiler is very approachable and needs contributors, by the way.) But, especially as a newbie, this kind of stuff can bite you. JVM Clojure is more polished. 1. http://dev.clojure.org/jira/browse/CLJS-639 http://dev.clojure.org/jira/browse/CLJS-639
- ninetax 13y ago
  Well that is pretty tempting! I would be inclined to contribute if I was working on some project where it made sense to use ClojureScript. Perhaps in a couple months when I start working on front end stuff I'll have the chance! Thanks!
- masklinn 13y ago
  > JVM Clojure is more polished. I wouldn't say that. In this case for instance it more or less just shoves java's error message in your face, you have to translate that back into the clojure you typed beforehand.
  - graue 13y ago
    OK, I can see the case for that nitpick. Perhaps neither implementation is particularly "polished" in this regard, and the JVM one just happens to fail faster due to a statically-typed host environment. Polished or not, though, the end result is Clojure being more helpful when you make typos/newbie mistakes.

by ninetax 13y ago

Yeah maybe in general but what about a comparison for heavy IO applications? core.async vs node's system? I really hope Clojure catches on. It's so fun to write in, I'm never going back!

deleted 13y ago

[deleted]

film42 13y ago

Real quick: I wrote a little json-in-json-out app for working on webapps before the backend is done (first node (express)). Then, later rewrote it in clojure (compojure). They're both on heroku and perform about the same. This is by no means a real benchmark, but does show that node can keep up with the JVM for ridiculously simple apps. Node version: http://json-mirror.herokuapp.com/ http://json-mirror.herokuapp.com/ Clojure version: http://mirror-clojure.herokuapp.com/ http://mirror-clojure.herokuapp.com/ Also, ClojureScript is super interesting because a lot of clojure libraries will work (provided they're not a Java wrapper library) automatically. Draw backs though? Speed. ClojureScript uses Google Closure to optimize, which brings it close to pure JS speeds, but according to Conrad Barski, the webfui creator, it's not quite there. Check out his presentation though here if you're interested (demos and speed explanations included): http://www.youtube.com/watch?v=HeI5-D7SQe8 http://www.youtube.com/watch?v=HeI5-D7SQe8 CRAP: Should have replied to parent comment, but it's fine here as well.

ninetax 13y ago
Thanks! I'll take a look!

graue 13y ago

I'm not aware of a good reason to prefer ClojureScript+Node.js in general. Maybe if you wanted interop with a specific Node library, but otherwise, Clojure on the JVM will tend to have vastly better performance, and the tooling is better. For example, until recently ClojureScript's :keywords were just strings under the hood and it required a string compare to test equality. Apparently this is no longer the case due to this commit 2 months ago: https://github.com/clojure/clojurescript/commit/2cef52840fcd9d88f077d374cc81e50c7e645b9f https://github.com/clojure/clojurescript/commit/2cef52840fcd... but it shows you the kind of stuff you might run into. In a recent talk I saw by David Nolen, the lead maintainer of the ClojureScript compiler, he brought up multimethod dispatch as something that can still be as much as 100 times slower than the JVM. As a tooling example, Clojure gives you helpful errors if you initialize records the wrong way: user=> (defrecord Thing [foo bar]) user.Thing user=> (Thing. 1 2) ; correct usage #user.Thing{:foo 1, :bar 2} user=> (Thing. 1) ; wrong number of fields CompilerException java.lang.IllegalArgumentException: No matching ctor found for class user.Thing, compiling:(/tmp/form-init7089728177345913731.clj:1:1) user=> (Thing 1 2) ; forgetting the dot RuntimeException Expecting var, but Thing is mapped to class user.Thing clojure.lang.Util.runtimeException (Util.java:219) That's good! Especially if you're new to the language. You see where you messed up right away. But ClojureScript just silently gives you nils: ClojureScript:cljs.user> (defrecord Thing [foo bar]) cljs.user/Thing ClojureScript:cljs.user> (Thing. 1 2) ; correct usage #cljs.user.Thing{:foo 1, :bar 2} ClojureScript:cljs.user> (Thing. 1) ; wrong number of fields #cljs.user.Thing{:foo 1, :bar nil} ClojureScript:cljs.user> (Thing 1 2) ; forgetting the dot nil This should be a bug report against the CLJS compiler (edit: now it is[1]), and it's probably not that hard to fix. I could fix it. You could fix it. (The CLJS compiler is very approachable and needs contributors, by the way.) But, especially as a newbie, this kind of stuff can bite you. JVM Clojure is more polished. 1. http://dev.clojure.org/jira/browse/CLJS-639 http://dev.clojure.org/jira/browse/CLJS-639

ninetax 13y ago
Well that is pretty tempting! I would be inclined to contribute if I was working on some project where it made sense to use ClojureScript. Perhaps in a couple months when I start working on front end stuff I'll have the chance! Thanks!
masklinn 13y ago
> JVM Clojure is more polished. I wouldn't say that. In this case for instance it more or less just shoves java's error message in your face, you have to translate that back into the clojure you typed beforehand.
- graue 13y ago
  OK, I can see the case for that nitpick. Perhaps neither implementation is particularly "polished" in this regard, and the JVM one just happens to fail faster due to a statically-typed host environment. Polished or not, though, the end result is Clojure being more helpful when you make typos/newbie mistakes.