13 ms·
The Node Ahead: JavaScript leaps from browser into future
- lalc 16y agoThis is going to provoke massive eyerolling over at the Erlang industry.
- JonnieCache 16y agoSomehow I don't think rolling their eyes at developers discovering a need for what they have to offer will do the Erlang community any good. If they sincerely believe that Erlang offers a superior alternative to Node for what the influx of new Node developers need, then they should be looking to provide resources to help these devs "graduate" to erlang. Not once have I seen a blog post saying "Like Node.js? Then you're going to love Erlang! Let me show you why it's better, with some snippets to compare and contrast."
- eberfreitas 16y agoI would love to read such article!
- lalc 16y agoOh, I agree. Every time someone advocates Erlang they mention how it was used to build super-reliable telecoms and they start mentioning three-letter acronyms and immediately everyone's eyes glaze over. It just isn't sexy like node (yet?).
- deleted 16y ago[deleted]
- drdaeman 16y agoThere are always Efene and Reia if you want sexy things. (However, I find it somehow disturbing that there are almost no documentation on Reia beyond the examples on its site's start page.) One could compare Node.js to Twisted, Tornado or EventMachine. However, comparing Erlang to Node.js is somehow weird as they have different paradigms — Erlang is highly-concurrent with its "green" processes, while Node is single-process single-thread with "asynchronous" paradigm. (However, there are some aspects, that could be compared. Erlang has "let it crash" motto, while in Node.js one has to be careful with any exceptions. Erlang is distributed and Node.js has no notion of processes.)
- flogic 16y agoI like different languages but Erlang is like Lisp in that it has yet to really grab me. The difference being, Lisp has far better odds of grabbing me. As far as I can tell, Erlang's advantages can be cloned elsewhere in more pleasant to work with languages.
- gloob 16y agoCould you list what you consider to be Erlang's advantages? Most of the ones that I can think of off the top of my head fall into the range of "possible to clone, but would take a huge amount of engineering effort" (e.g. OTP), or alternatively "a culture issue" (e.g. "let it crash", and the language's completely obsessive focus on application stability, both of which are pretty much diametrically opposed to the common language philosophies today).
- flogic 16y agoI was thinking primarily of "let it crash" and "message passing". They don't seem particularly tied to the language. I'm not familiar enough with the OTP to comment.
- route66 16y agoI must have missed the current common language "philosophies", at least what concerns their opposition to focus on stability ... what are these? Can I avoid them?
- gloob 16y agoC is not a language optimized for stability. The possibility for segfaults, buffer overflows, etc. and the lack of a sensible mechanism for handling them other than "write the program correctly" demonstrate this. It is, essentially, a language optimized for writing Unix. Shell is not a language optimized for stability. It is optimized for interactive use, above all else - it's not even a very good scripting language, even though it's historically been used that way an awful lot. Python is not a language optimized for stability - it's not even mentioned in the Zen of Python: http://www.python.org/dev/peps/pep-0020/ http://www.python.org/dev/peps/pep-0020/ The primary focus of Java (at the time of it's creation) was "write once, run anywhere". The primary focus of Java (now) is "languages that compile to JVM bytecode are nifty - plus, we have C-like syntax but are a high-level language". The primary focus of Erlang, before and above anything else, is program stability. OTP exists to increase stability. "Let it crash" exists to increase stability. Parallelism and message passing are in the language not because they're neat, but because (if they are used at all sensibly) they will increase stability.
- pchristensen 16y agoThe talk about node.js over the last few months caused me to buy an Erlang book this week. In at least one case, you're onto something.
- evgen 16y agoNot once have I seen a blog post saying "Like Node.js? Then you're going to love Erlang! Let me show you why it's better, with some snippets to compare and contrast." Given the fact that there already exist bridges that can take javascript snippets and run them in sub-processes within erlang I am really surprised that no one has bothered to do a "enode" system that just provides a node-like api for the callouts to the javascript processes.
- RyanMcGreal 16y agoHow close is couchdb? Couch is written in erlang but communicates over HTTP via JSON.
- querulous 16y agonot very close. couchdb can only run javascript functions on json objects, and really only to transform those objects into other objects. last i checked, it has no way of interacting with the erlang node it's hosted on.
- yalogin 16y agoDon't worry Node can handle all the eyerolling with ridiculous speed and low memory consumption.
- SandB0x 16y agoOne page version: http://www.theregister.co.uk/2011/03/01/the_rise_and_rise_of_node_dot_js/print.html http://www.theregister.co.uk/2011/03/01/the_rise_and_rise_of...
- Legion 16y agoWas the problem really that Python was slow, or did they not discover event-driven until finding Node?
- sh1mmer 16y agoVoxer were using Twisted and found it too slow. Matt told me he had VM issues with Python.
- chapel 16y agoThe problem with other even-driven frameworks out there is that they have too much existing codebase that is blocking, which is why Ryan Dahl went with javascript. It had no preconceptions how to do things, and didn't have a large library of modules and code that it would need to interface with that caused it to block. Python isn't slow by any means, but I think for what they were trying to do, node.js really fit their use case better. Being able to hook up so many different types of functionality all into one 'application' is really freeing especially considering how approachable it is.
- jrockway 16y agoI love Node, but I don't think this is particularly true. I have had no problem writing Event-driven Perl apps that talk to web users, use ZeroMQ, talk to a SQL database, talk to Redis, read from disk, and spawn external processses... with none of those operations blocking. Look at the AnyEvent:: namespace on search.cpan... there's a quite a bit of stuff there. Everything that Node has, and more. You should use Node because you like Javascript, not because other languages don't have as good of libraries... because other languages have as good of libraries.
- pohl 16y agoJust as this story came up I was watching the video of Ryan Dahl explaining Node.js (someone had shared this link in the recent thread about the event loop) http://developer.yahoo.com/yui/theater/video.php?v=dahl-node In it, Ryan makes an important point about JavaScript being a natural fit because it was designed for a constrained environment. In particular, there is no way of doing I/O in JavaScript's traditional browser environment without providing a callback argument (I'm not counting interacting with the DOM as I/O here, and a couple of pedantic exceptions pointed out by judofyr below), and for the way in which the browser guarantees that only one callback will be executed at a time. I think this idea of a constrained environment is very important. If blocking I/O functions are strewn about the APIs you have at your disposal, then programmers tend to default to using them. The other point he makes is that often evented APIs are just missing from the underlying platform. Does every way of doing some sort of I/O in the universe of Python APIs have variants that take callback arguments? Even if the answer is 'yes' (which would surprise me) there is a minefield of blocking calls one would need to avoid in a disciplined manner. ...which may not be easy. Tell me: does myAwesomeFunction() do some blocking I/O under the hood? You can't tell from the name. Do the docs always make that clear, and provide an alternative with a callback? Edited to include judofyr's exceptions — which bolster rather than undermine the point, because note that window.prompt's raison de'etre is to block for user interaction, and document.write is a RAM operation rather than disk or network I/O.
- chapel 16y agoAlthough the ideas and technology behind node.js aren't entirely new, the fusion of a well known client side language like Javascript and a robust server-side event based architecture really makes node.js great. I really enjoyed the article because it approached node.js as it should have, as the new way of doing things on the server. I see node.js becoming as ubiquitous as ruby/python/perl are on the server (maybe even for desktop applications). Even if node.js doesn't become as big as I think it will, I feel that the shift is has helped cause is a positive one for the server space and we will all benefit from it.
- mcantelon 16y ago>We're still a long way from a 1.0 release. Version 0.4 arrived just last month. If memory serves, 1.0 is not so far way... half a year? When node hits 1.0 and there is a perception of API stability, third-party development will likely explode.
- dennyferra 16y agoAnd there's plenty of third-party development already happening: https://github.com/joyent/node/wiki/modules https://github.com/joyent/node/wiki/modules
- tluyben2 16y agoNode.js is great stuff. It's not new (as far as concepts used), but really nice to work with. Javascript tools and runtimes are growing up very fast; it'll probably go on to surpass Erlang for this purpose if the libs are stable enough. Node.js was the killer framework for JS anyway.
- evgen 16y agoJavascript tools and runtimes are growing up very fast; it'll probably go on to surpass Erlang for this purpose if the libs are stable enough. I don't know whether to laugh or to cry... Node/JS may replace EventMachine/Ruby or Twisted/Python for quickly whipping up an evented app or service, but it will be quite a while before anyone would consider moving an erlang project to node. Node is little threat to the distributed, fault-tolerant, concurrent niche that Erlang occupies -- within that realm there is nothing you can do in node that can't be done better in erlang and a great deal of bulletproof infrastructure in the frameworks built up around erlang and its vm that node will never come close to.
- randylahey 16y agoHoly FUD! I'm sure all the Lisp and TCL fanboys thought the same of their supposedly superior runtimes all the way to eventual irrelevance. Hubris much?
- SamReidHughes 16y agoUm. What he says is basically true. Node is never going to replace Erlang for the same reasons it will never replace C++. Erlang is simply different from Javascript and no amount of runtime improvement can change that.
- gtani 16y agoNot sure what "replace" and "threat to erlang" means, but: for shops that already run the JVM and .NET, I think many'd be inclined to look at akka (or scala actors) and asynch workflow as available today in F# (and promised for C# 5/.NET 5). But the important thing is that erlang is no static target, development is going very strongly: read the release notes for e.g. R14A, B and B-01.Ask questions on the mailing list if you're not sure what something is, they're very friendly. (maybe someday they'll fix apache not to give out direcotry listings like this ;-> http://www.erlang.org/download/ http://www.erlang.org/download/
- jimmyjazz14 16y agoNode is really good, until it's not. I've actually spent a lot of time with Node since the company I work for was an early adopter. This all based on opinion but, my general feeling about Node is that the underlying concept is great but, Javascript is an awful language to do it all in. The lack of real support for continuations (and/or coroutines) means there is no escape from the callback hell and tracking down errors can be a real nightmare. Ultimately for simple projects Node works fine but reach a point where your application becomes at all complex and things can get hairy real fast (of course this statement could be made about client side Javascript as well). I say this not to discourage anyone from trying Node because for many projects Node may be just what you need but, there are some downsides one should probably keep in mind.
- corysama 16y agoI am not an expert on Node. But IIRC, Dahl tried and rejected a coroutine style for Node. The problem was that context switches that may or may not happen inside of any function that you call end up creating consistency problems that are almost identical to the thread-safety issues that he was explicitly trying to avoid by creating Node.
- beagle3 16y agoDo you have pointers for that? That really surprises me, as the two are essentially equivalent, except that function closures as in Node introduce a new, restartable (usually an unwanted/unexpected featture) scope, and coroutines maintain the same scope. Thread safety problems are all about data changing in between your statements due to some other threads. Coroutines make that happen only along calls to other routines, which is very disciplined.
- DTrejo 16y agoBy the way, node is built on V8. I get the impression that Ryan is not at all interested in inventing a new language. He is interested in a language that runs quickly. Anything outside of the scope of JS run on V8 inches into the "new language" designation. Basically, any syntax you couldn't use in the browser is a no-no. Note: this is just my impression.
- drdaeman 16y agoNot too long ago I've written some simple CAPTCHA service with Node.js, node-redis and node-canvas. It was a simple application that generated a word from a specific grammar, saved it to Redis for further reference and returned a PNG. While being ridiculously fast it leaked memory like crazy. So I've found that there were almost no debugging tools (except for old good gdb) to find out what was going on. (I've heard that there are some changes like `node debug`, though. Should dig the archives and try code with latest Node version.) I believe this was an inherent consequence of JavaScript and V8 being tailored to short-lifetime (milliseconds of DOM operations, then lazy waiting for events to fire) applications with low amount of events (user in-browser activity).
- jrockway 16y agoI believe this was an inherent consequence of JavaScript and V8 being tailored to short-lifetime (milliseconds of DOM operations, then lazy waiting for events to fire) applications with low amount of events (user in-browser activity). Nope, it's just bugs. Every programming language has memory-related bugs... just less of them as they get older.
- jderick 16y agoIt seems like event based programming would be really cumbersome in comparison to having lightweight threads ala Erlang. Perhaps Javascript needs lightweight threads?
- gustaf 16y agoIf you're into Node.js and Redis we (Voxer) are actually hiring engineers. We're building a Walkie Talkie for iPhone and Android. In more technical terms Voxer is a low latency messaging system for voice, images, and text. We have an iOS client in the App Store, and an Android version is in the works. We've had explosive growth in the last couple of weeks and are now in top 25 in a bunch of app stores and we are looking for someone to help us develop the server side components and make the system scale. Email me gustaf@voxer.com if you want to know more and I'll connect you with the right person. Our servers are built out of Node.js, CouchDB, and Redis. If you are excited about node, server-side JavaScript, and new databases, this is an opportunity to work on this technology full-time.
- bnchdrff 16y agoThe author coined "developerati" and I gagged.