Yes you can do anything in C++
including spending some much time farting around with low-level stuff instead of actually fulfilling business requirements that the whole thing goes boobs aloft.
Voxer is a walkie-talkie for the modern age, an iPhone app that lets you instantly talk across the interwebs and listen at the same time and leave voice messages if no one is on the other end and simultaneously chat with multiple people and toggle between text and voice to your heart's content. It's a real-time internet app in …
That's probably not a great idea. Event-driven architectures are fine for the cases in which the work required between events is small and/or approximately the same for each event. Any application which requires a significant period of processing in response to an event is going to have to yield to other event-handling sufficiently often to ensure other activities don't stall - and that's just multithreading by a different name.
FSMs (that's finite state machines) are great for things like network protocols - get a packet, do something, send another one - but the more complex the "do something" is and the more you have to break it down into individually-schedulable events the more the code looks like another kind of FSM, the Flying Spaghetti Monster [no offence to disciples intended....].
One of these days somebody will produce an OS as clean and easy to use as the old Amiga OS (before the "magic" UI and other stuff took over that is). The OS rendered your application, including the buttons controls and everything. As a developer you just provided event handlers to the button presses and any custom rendering required. It was simple, efficient and applications remained largely efficient and consistent.
It wasn't all good, of course, but it was a very good start. Applications tended to (want to) become more complicated than the OS would allow and they would sometimes start to take over the OS's tasks on their own as a result, but as a principle it was good.
I still miss the lack of damn drive letters, obscure mount points and other arcane chicanery as everything was just assign points. The first versions of the OS didn't scale this concept too well but later revisions improved the handling considerably. Being able to access your application's assign point on the file system and not caring whether it was a diskette, CD, obscure mount point within the directories on a hard disk or even a remote file system was a delightful way to handle files. Libraries were handled by the OS and versioning was the norm - it could still lead to library (DLL in windows land) hell but unlike early Windows handling of such libraries it was manageable.
I think that nowadays any discussion on JavaScript and its use both client-side and server-side, should also include a mention of the Haxe language too. Haxe is JavaScript like language, but is more strongly typed (ECMAScript 5 is proposing some typing too), allowing you to write in a "safer" coding style, and then auto-translate your classes to other languages like JavaScript, ActionScript, PHP, C++ (with C# and Java planned in the future too).
So Haxe is another option worth considering if you want one language for both client and server side web development, and I guess it should be possible to use it with JavaScript server-side environments like Node too, if it offers some other QA or flexibility/portability benefits.
Node.js is just the Google V8 engine bolted on libev...
Just like Twisted is Python bolted onto libev...
Just like Ruby and Lua can/have been easily bolted onto libev or libevent...
In fact, any language with the concept of callbacks or closures can be bolted on libev.
So is the excitement that it's JavaScript they have bolted on top?
Naturally, libev is written in C, and yes, I throughly recommend it to anyone who wants to do some serious Unix event-driven server development (I am not the author!)
And... libev has limited support for Windows, and the author has no intention of making it better as the I/O model is so different.
"man 2 select"
Quite. Single threaded event driven programming is as old as the hills and using select() or poll() in C/C++ is pretty bloody simple for any coder with half a brain and is also the first thing you learn how to do when writing a network server app in C.
In fact you don't even have to multiplex just network sockets with them , you can use unix sockets, pipes and other file system objects too thanks to Unix making socket and file descriptors equivalent in a lot of scenarios (unlike Windows). Try doing that with javascript "event" programming.
The point about Node.js is NOT that it is JUST event-driven. Yes all you old farts, we understand that this is not new.
The point is that JS gives you the syntactic sugar to string together multiple continuations into what looks like complete processes without the hassle of having to track "conversations". So you get something that looks like thread/request, but running underneath like event actors with the concomitant increase in throughput. Any language with good closure support can do this, but JS is the mainstream one ATM.
BTW, there are other more performant frameworks doing this kind of thing on the JVM. Google Loft (Scala) and (as far as Java allows it) Deft Server (Java) for info.
"multiple continuations"
"complete processes"
"conversations".
"event actors"
"performant frameworks "
Sorry , I'm confused , was your post trying to make a point or was it just todays buzzword bingo game?
Reading between the lines of all that guff I think you're saying that javascript makes it easier for script kiddies to write servers because all the actual hard stuff has been done in a library written by someone else.
Sorry you didn't understand my post. I had hoped the terms I was using would be familiar to those who have tried to do this stuff for real.
But your final remark is true, up to the point that any framework or library is intended to make things easier for the user. So I'm not sure you can prove anything by it.
BTW, there is a "Reply to Post" button.
Kit, you just proved your opponents point, nice own goal. To summarize your post:
"event driven is hard, but Node.js give you 'syntactical sugar' to make it almost as easy as using a multi-threaded language which keeps state for you in the stack".
That said, to the old timers: yes, its been possible to do all this forever, but now you can do it in a language that will run on *any* device. Kinda like Java promised, but for real this time :-P
Certain people here, including - it would appear - the author of TFA, seem to think that the term "multi-threaded" is synonymous with using blocking I/O to service one session per thread, whereas "event-driven" is synonymous with using a single thread to service multiple sessions via the magic of non-blocking I/O. I hate to break it to you, but all "multi-threaded" means is that a process spawns multiple threads, it doesn't have to dictate an entire server architecture. In a similar vein, if when you say "event-driven" you really mean "uses non-blocking I/O", then just say so.
The blocking I/O, one-session-per-thread architecture began life as one session per child process, on OSes where IPC doesn't suck, and fork not only exists but provides decent copy-on-write memory sharing - i.e. not Windows. It seems to have become fashionable to use the same architecture, but with threads in place of child processes, mainly because of a certain OS's handicapped notion of child processes. Oh, and because we're always told threads are difficult to work with, so being able to make them work must make you a l33t h4x0r, amirite? OK, so in-memory message passing can be faster than true IPC, but the genuine potential benefits of multi-threading don't seem to be the main reasons why people use it.
On the other hand, a *single-threaded* event-driven architecture will very quickly stop performing if you actually need to do anything CPU-bound with your data, as opposed to simply shunting it from source to sink. Notice, though, that at no point have I mentioned multi-threading (using the real definition, not the article's definition) and event-driven concepts being mutually exclusive - you'd just better do it that way from the ground up, because bolting multiple threads onto existing single-threaded code is no less a recipe for disaster than trying to turn blocking procedural code into non-blocking event-driven code. I'm not saying it's easy to get right, either; you can find yourself bogged down by the overheads of things like context switching and message queue locking very easily. Don't try and do it on Windows, either, because IME it just doesn't have the APIs to do the approach justice.
Nowt wrong with a bit of C++; if you can learn to use the POSIX socket API, your understanding of pointers and memory management ought to be up to snuff for most things you'll need to do in the real world. (Bloody sockaddr structures, bane of my existence.)
Oh, and I'm only in my 20s, so hopefully there is *some* hope for future generations....
But I bet you are one of the "rare" hobbyists who then went on to do this stuff professionally? Someone who actually enjoys poking about with the software and learning how to actually get it to talk to the hardware (without an interpreter), who, had you been a wee bit older, would have copied the source code for Manic Miner for the BBC model B from a magazine and then spent hours debugging it and getting the glitches out just to see if you could!
Many "younger" programmers don't seem to _want_ to know more, aren't prepared to look "under the hood" and many (unfortunately) don't know anything outside Windows ... or worse yet, .NET - if it can't be done in .NET they're stuffed.
For them it's just a job - some of us, and I'm guessing you're one, actually love this shit :)
All this newbie code monkey jabbering, click-jerk down-voting and inter-generational cluebat swinging. I really, really, really, could do with a few pints about now to deaden the pain of it all.
Oh yes, I was going to say something about measuring bottlenecks, profiling and such. Too late, I've already got my coat on. Have a good weekend all.
I read this and was not impressed. Long before I would decide to build a library for Javascript so that I could build a VOIP server based on it, I would exhaust all the other options... Like people here have already said, C++ similar would be fine. What takes less effort? Developing Node JS, or learning how to use an existing, mature and well supported language?
So I blogged about it: http://blog.maxant.co.uk/pebble/2011/03/05/1299360960000.html
Summed up: it didn't take long to implement a little Java app capable of doing what the author of Node JS was wanting to do - have a server capable of using up all the possible ports for incoming requests.