Earlier quoted context omitted.
Have you tried Haskell? Why haven't you tried Erlang? They're both good choices for writing applications that handle making and receiving thousands of concurrents requests because they have very fast lightweight threads and good exception handling and you don't need to write the kind of code that Node.js forces you to write.
Node is appealing because Javascript is ubiquitous, but I doubt it's harder to learn Erlang than it is to learn to write everything in nested callbacks.
Node.js - A Giant Step Backwards
21–30 of 117 posts
Re: Node.js - A Giant Step Backwards
#22Meanwhile there are other choices that are about as easy, like Python libraries and Google's Go. Too bad they don't have the same zealous community support.
Re: Node.js - A Giant Step Backwards
#23The V8 team is thinking of adding yield/defer support to make programming in Node neater. There's hope yet. Meanwhile there are other choices that are about as easy, like Python libraries and Google's Go. Too bad they don't have the same zealous community support.
Re: Node.js - A Giant Step Backwards
#24The V8 team is thinking of adding yield/defer support to make programming in Node neater. There's hope yet. Meanwhile there are other choices that are about as easy, like Python libraries and Google's Go. Too bad they don't have the same zealous community support.
Hmmm, interesting! I hadn't heard about that - Do you have a reference URL?
Re: Node.js - A Giant Step Backwards
#25If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore. I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades a…
Re: Node.js - A Giant Step Backwards
#26If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore. I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades a…
Ship it tomorrow! ;)
Yes, you have overlooked something important, there will be something to be embarrassed by -- whether it turns up next week or next decade -- and we'll all have a good laugh. Don't sweat it. And don't worry that the thing isn't finished; the kind of geeks who might sign on at this stage like unfinished things; that is why they can't resist reinventing the wheel. Plus, it doesn't have to be finished to give people ideas, which is half the point. You are ready to start spreading the news; your writeup says as much.
The public repository beckons!
(Frankly, this sounds like a great experiment, although I would never be too quick to predict the end of the ops department. ;)
Re: Node.js - A Giant Step Backwards
#27If you're interested in keeping up to date with the project I describe below, please follow me on twitter @NirvanaCore. I had many of the same concerns with node.js. Every time I attempted to wrap my head around how I'd write the code I needed to write, it seemed like node was making it more complicated. Since I learned erlang several years ago, and first started thinking about parallel programming a couple decades a…
Sounds like you're about a month ahead of me. For what it's worth I also think that my very similar idea is genuinely new— best of luck!
Re: Node.js - A Giant Step Backwards
#28This purist evented I/O fundamentalism has to stop. While evented I/O is great for a certain class of problems: building network servers that move bits around in memory and across network pipes at both ends of a logic sandwich, it is a totally asinine way to write most logic. I'd rather deal with threading's POTENTIAL shared mutable state bullshit than have to write every single piece of code that interacts with anyt…
It won't work for every problem, of course.
dnode is a good way to easily talk to other node.js processes without the HTTP overhead. It can talk over HTTP too, with socket.io.
node-http-proxy is useful as a load balancer, and a load balancer can distribute work between cores.
Finally, most of the node.js people I've met, online and offline, are polyglots, and are happy to pick a good tool for a job. But right now node.js has great libraries for realtime apps, the ability to share code on the client and server in a simple way, and good UI DSLs like jade, less, and stylus.
Re: Node.js - A Giant Step Backwards
#29In my experience Node.js is more difficult than synchronous code. But it's also, by far, the easiest way to get something running that's massively parallel. I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performan…
> I recently wrote a project that needs to do 100's or 1000's of possibly slow network requests per second. The first try was Ruby threads. That was a disaster (as I should have predicted). I had an entire 8-core server swamped and wasn't getting near the performance I needed. I don't mean to be offensive, but welcome to at least the 1980s. We've known this doesn't scale for ages. The fact that you even tried it and…