8 ms·
Clojure's edge on Node.js
- kouPhax 16y agoNot a massive fan of clojures syntax though - that example is like bracket city!
- stanleydrew 16y agoPeople say similar things about javascript.
- twism 16y agoCounted the same number of brackets in both Node.JS and Clojure examples.
- kouPhax 16y agoThat may be but it doesn't stop the clojure code looking messy IMHO. Feels less structured (again IMHO)
- khingebjerg 16y agoIn my eyes it's more structured, since it's all data structures.
- abp 16y agoThis sounds like: I don't know how clojure works. I know how clojure works. ...
- francoisdevlin 16y agoIt's not bracket city, those are all Clojure data structures. The example could also be written like this: http://gist.github.com/468107 http://gist.github.com/468107 Code is data :)
- compay 16y agoSyntax aesthetics shouldn't be an important metric for technology choices.
- kouPhax 16y agoThey "shouldn't" be, but more often than not they are. At least in my experience of try to introduce people to new languages/technologies.
- Calamitous 16y agoWhy not? Aesthetics improve readability and maintainability, (probably) trading out for less raw speed. If I'm less concerned about performance than maintainability, why shouldn't aesthetics play a large role in my decision?
- deleted 16y ago[deleted]
- nullstyle 16y agoFor me, unfamiliarity with a syntax is easy to confuse as poor aesthetics of the syntax. I got to the point of understanding and enjoying clojure's syntax very quickly.
- compay 16y agoBecause it can lead you to make arbitrary choices. People usually disagree vehemently on matters of aesthetics. I didn't say it shouldn't play any role, it just shouldn't be an important one. Focus too much on syntax over semantics and you're bikeshedding.
- LaPingvino 16y agoI get lost easily in non-lisp-code nowadays =x The unwritten standard for lisp indentation works out quite readably
- InclinedPlane 16y agoCounter-point: http://en.wikipedia.org/wiki/Brainfuck http://en.wikipedia.org/wiki/Brainfuck
- cageface 16y agoThreads aren't going to scale to the same number of concurrent clients as an evented system though. Isn't that the whole point of things like node? Serving huge numbers of relatively lightweight requests?
- nullstyle 16y agohttp://www.jboss.org/netty/performance/20090607-asalihefendic.html http://www.jboss.org/netty/performance/20090607-asalihefendi... At the very least some hackers out there are able to make it scale quite well. Does anyone have a comparable anecdote for Node.js (honest question)?
- shorrockin 16y agoplurk themselves recently moved away from netty and towards node. While you could argue this was a bad choice, it is an interesting footnote: http://amix.dk/blog/post/19490#Plurk-Instant-conversations-using-comet http://amix.dk/blog/post/19490#Plurk-Instant-conversations-u...
- babo 16y agoThis IS an evented system.
- cageface 16y agoI was referring to the second example, using threads. Specifically this claim: In Clojure we don't need to use callbacks. This means for common things like talking to databases, we don't need them to have asynchronous interfaces. That's because we have really fantastic primitives in the language itself for dealing with concurrency. This code runs twice as fast as the Node.js counterpart - probably due to the excellent perf of Clojure coupled with leveraging multiple cores.
- mcav 16y agoThey don't use infinite threads, just a thread pool.
- jherdman 16y agoThat's pretty neat. I've been meaning to learn about Clojure. This is just the thing I needed to encourage me to get off my duff.
- ericb 16y agoI'm not familiar with node.js. What engine is used to run the stand-alone JS? Is it inevitable that is it limited to a single core?
- ionfish 16y agoNode uses Google's V8 virtual machine, which they built for Chrome. JavaScript is single-threaded, so yes, unless you spawn a child process it'll be limited to a single core.
- ericb 16y agoIs being single-threaded part of the JavaScript spec?
- ionfish 16y agoOnly implicitly: no threading model is documented in the ECMAScript Language Specification [1], and no widely-used interpreter implements threading. The new Web Workers specification adds something like threading to JavaScript in the context of the browser [2], and Node intends to add support for this on the server as well [3]. Have a look at [4] for a nice article on threading in JavaScript. [1] http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf http://www.ecma-international.org/publications/files/ECMA-ST... [2] http://www.whatwg.org/specs/web-workers/current-work/ http://www.whatwg.org/specs/web-workers/current-work/ [3] http://nodejs.org/ http://nodejs.org/ [4] http://odetocode.com/blogs/scott/archive/2007/01/08/javascript-and-threading.aspx http://odetocode.com/blogs/scott/archive/2007/01/08/javascri...
- srveit 16y agoIt uses Google's open source V8 JavaScript engine. (http://code.google.com/p/v8/ http://code.google.com/p/v8/) It doesn't support multiple cores AFAIK. To use multiple cores, the server would need to spawn subprocesses or run multiple servers behind nginx.
- sjs 16y agoThis looks really nice! Our server is based on Node right now but we've had the idea of porting to Erlang later. Maybe Clojure + Netty is another option to explore.
- IsaacSchlueter 16y agoThat's not really a valid test. NodeJS can easily make use of multiple cores with child processes, but by design, it's a very low-level API, so that stuff isn't used by the HTTP server by default. In other words, it doesn't assume you want to use multiple processes for your HTTP server. Maybe you want to use them for something else. (Like, if you have an HTTP server and an IRC server sharing the same box, and you want to make sure they are isolated from one another, or something.) Check out http://github.com/kriszyp/multi-node http://github.com/kriszyp/multi-node or http://github.com/extjs/Connect http://github.com/extjs/Connect for examples of web servers that will blow Clojure out of the water in this benchmark. When leveraging multiple cores, NodeJS is closer to nginx in terms of performance than it is to Jetty or Django. (Of course, nginx uses almost no memory, and NodeJS has this big honkin VM juggling JavaScript contexts, so it's not as space-efficient.)
- barrkel 16y agoMultiple processes are an inefficient way of making use of multiple cores. Either you pay memory overhead to duplicate state, or you pay IPC overhead to get access to shared state of some kind.
- ppplll 16y agoassuming you proxy requests to the different processes. that's not what those examples are doing - they simply share a server socket and let the kernel load balance incoming connections over them.
- sedachv 16y agoIn many cases it's more efficient precisely for the reasons you mention. Data duplication removes locking and cache coherence penalties. If you structure your program to communicate by message passing over IPC (for example, via a database) you get those benefits, plus possibly more efficient mutual exclusion mechanisms (CAS, tuned MVCC, etc). Also, don't forget that GC penalties are going to be paid by all threads in a process.
- 16y ago
- felixge 16y agoNode's requests/second scale linearly with the amount of processes used. Here is an example for doing that: http://gist.github.com/430932 http://gist.github.com/430932 So node would probably outperform the given clojure example by 13.5K req/s vs. 8.5k req/s (YMMV). It is also worth noting that clojure library used (aleph), does not seem to support streaming the response. The most interesting aspect is clojure's support for futures, and Javascripts lack of such. If you're willing to trade speed for cheap syntactical pleasure, clojure has an advantage here : ). edit: Who down voted this / why?
- swannodette 16y agoClojure should also scale very well on a real 4 core machine (it's the JVM after all). And I wouldn't be surprised if was neck-to-neck with Node.js. Without numbers it's just talk (I don't have access to a real four core machine so I can't say myself). Also I note that your code is very verbose for managing multiple cores while the Clojure version is pretty much identical to the original Node version. So much for cheap syntactical pleasures, eh?
- felixge 16y agoThe clojure example is using a library. There are libraries for node that make the process handling just as easy. Anyway, I think you are mistaken if you believe a clojure http server could outperform it's node counterpart. I mean node is really just a set of air-thin Javascript bindings to some pretty good C code / native system calls. Node's http parser is also written in C.
- icey 16y agoClaims are pointless without backing benchmarks. Being written in C is no guarantor of performance.
- felixge 16y agohttp://developer.yahoo.com/yui/theater/video.php?v=dahl-node http://developer.yahoo.com/yui/theater/video.php?v=dahl-node Shows node to outperform nginx for serving a static 1 MB buffer.
- mhd 16y agoThe main problem both systems have is that they're relatively immature. node.js is still undergoing heavy development, with a few breaking changes every couple of releases (although it's slowing down in that regard). And aleph basically just came out, right? So I'd regard both as "things to watch" or bootstrapping solutions, not something I'd use for my Global Thermonuclear War management system.
- stratospark 16y agoBut they're already using node to manage Global Thermonuclear War: http://wargamez.mape.me/ http://wargamez.mape.me/
- Periodic 16y agoI agree. I had a similar problem with CouchDB a while ago when I tried to write the application in CouchDB. The interface was there, but it was obvious that some of the key features hadn't been implemented yet, requiring painful and complex workarounds. I went back to technologies I knew were tried and true. If you're interested in playing around with tech and having fun, then these technologies are great. But for business I would avoid them for now. I'm hoping they gain some traction though.
- prospero 16y agoI wrote Aleph this weekend, so yes, it's very new. However, right now it's just a few hundred lines around Netty, which is anything but immature. I'm certainly not claiming it's flawless, or that there won't be any breaking changes in the future. However, I think this is a great example of one of Clojure's strengths: even brand new projects tend to have solid, well-tested foundations.
- mhd 16y agoWell, the same could be said about node.js and libev, to be honest.
- j_baker 16y agoOf course if that's what you're looking for, twisted[1] is the only way to go. [1] http://twistedmatrix.com/trac/ http://twistedmatrix.com/trac/
- Periodic 16y agoI initially had Javascript off, so I figured it was part of the joke when the space for the shortest Node.js web server was empty. When the shortest Clojure web server was also zero characters, I got suspicious. Don't forget to add a non-Javascript version for people without Javascript (rare) and bots (common).
- c00p3r 16y agobtw, did anyone have a look at node's sources? It is terrible mess. Actually, using something like nginx-pr (a-la apache's apr) would be much better solution than this bunch of hacks. But people never listen. ^_^