Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js - A Giant Step Backwards

fenn.posterous.com

Post reply on HN
Print view View original

51–60 of 117 posts

Re: Node.js - A Giant Step Backwards

#51

Post by rbranson »

chrisohara wrote: post #50
rbranson wrote: post #41

Earlier quoted context omitted.

Huh? how does any of this keep me from having to write callback spaghetti? If I send a call using redis or dnode or whatever, I have to wait for it, so that means a callback. I feel you about the polyglot and tend to agree, but I think some people are really trying to force awkward things into node, like people attempting to write big full-stack webapps using it.

the thinking that async code == callback spaghetti shit has to stop. There are plenty of async idioms that make callbacks a breeze.

I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest.

Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?

Re: Node.js - A Giant Step Backwards

#52

Post by nirvana »

apaprocki wrote: post #39
nirvana wrote: post #18

If 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…

Regarding 1), it is a great way to do things (never copy files around), but just make sure you have good release tools built around the db records. The approach that we use is that when things are published they automatically have a 'dev' release record for that version for the user that published it (so they can test) and individual versions have to be promoted ultimately to 'prod' for 'everyone'. The version you se…

This is going to be an opportunity for the community. :-)

I have some plans in this area, but I couldn't guess how to best fit into other people's workflows.

What might be nice is if there was a way to sync a git repository with Riak, and then Nirvana could just pull the relevant code from that. Seems like it would be the best solution, but looking into that- from looking at possibly integrating with a github API (do they have one?) to command line scripts is something I'm punting on to focus on the essentials.

But I do agree with your points!

Re: Node.js - A Giant Step Backwards

#53

Post by chrisohara »

rbranson wrote: post #51
chrisohara wrote: post #50

Earlier quoted context omitted.

the thinking that async code == callback spaghetti shit has to stop. There are plenty of async idioms that make callbacks a breeze.

I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?

Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing.

You obviously haven't written a lot of async code so not sure why you're so against the idea.

Re: Node.js - A Giant Step Backwards

#54

Post by rodion_89 »

gcr wrote: post #34
randylahey wrote: post #17

Earlier quoted context omitted.

It's kind of a dick move to make a inflammatory, flamebait blog post and then later admit you didn't actually know what you were talking about. Maybe you should have actually understood the technology you were working with before making knee-jerk snap judgements.

How was your first experience with node.js different than Fenn's?

Honestly, if you have ever done anything substantial in JavaScript then asynchronous functions with a callback pattern should not be such an issue.

Perhaps if your background is more on the lines of traditional server-side web development (ie. PHP, Django, Rails) then this is some new territory.

Re: Node.js - A Giant Step Backwards

#55

Post by apaprocki »

nirvana wrote: post #52
apaprocki wrote: post #39

Earlier quoted context omitted.

Regarding 1), it is a great way to do things (never copy files around), but just make sure you have good release tools built around the db records. The approach that we use is that when things are published they automatically have a 'dev' release record for that version for the user that published it (so they can test) and individual versions have to be promoted ultimately to 'prod' for 'everyone'. The version you se…

This is going to be an opportunity for the community. :-) I have some plans in this area, but I couldn't guess how to best fit into other people's workflows. What might be nice is if there was a way to sync a git repository with Riak, and then Nirvana could just pull the relevant code from that. Seems like it would be the best solution, but looking into that- from looking at possibly integrating with a github API (do…

Again, essentially what we do in concept. The dev side is a separate db (git could represent this), and once something is published past dev the record is copied to the production db (Riak in your case). The dbs have in-memory local machine cached versions, for speed, but also for reliability. You don't want your N machines depending on one db point of failure, so the local cached copies exist to mitigate that. (They receive updates via a multicast mechanism.)

Re: Node.js - A Giant Step Backwards

#56

Post by jacobmt »

nirvana wrote: post #18

If 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…

> The reason is, there isn't something like node.js for erlang, and so I set out to fix that.

That is not true, see: https://github.com/hookio/hook.io, been in development in Node.js for over two years.

Re: Node.js - A Giant Step Backwards

#57

Post by nirvana »

jacobmt wrote: post #56
nirvana wrote: post #18

If 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…

> The reason is, there isn't something like node.js for erlang, and so I set out to fix that. That is not true, see: https://github.com/hookio/hook.io , been in development in Node.js for over two years.

That looks like an interesting thing, but it is a something for node.js, not a "node.js for erlang".

By which, I meant to say "platform for building server applications in javascript, backed by the power of the erlang OTP platform."

Node.js gives server side javascript a platform, that's great. What I'm working on is giving server side coffeescript and javascript access to the erlang platform (and some really great erlang technologies.)

Re: Node.js - A Giant Step Backwards

#58

Post by yummyfajitas »

Just curious, is there a good futures library for Node? If so, you could write code of the form:

    x = db.getFutureResult("x");
    y = db.getFutureResult("y");
    whenFuturesReady([x,y], callback(x, y) {
        useResults(x,y);
    });
This looks reasonably similar to typical synchronous code,

    x = db.getResult("x")
    y = db.getResult("y")
    useResults(x,y)
but it allows db queries to happen simultaneously and doesn't break the node paradigm.

Re: Node.js - A Giant Step Backwards

#59

Post by rbranson »

chrisohara wrote: post #53
rbranson wrote: post #51

Earlier quoted context omitted.

I'll definitely admit that many of the inventive techniques that node.js users have come up with make dealing with callbacks less absurd, but the problem is that it's just polishing shit. It's extra hoops to jump through with no benefit, outside of the C10K fapfest. Would all the developers writing apps on node.js who are doing 10,000+ concurrent requests per process please stand up?

Only the minority gives a shit how many Hello World requests your stack can pump out. Some of us use node.js because it's a) got some decent libraries, b) makes realtime easy, c) uses the same code server+client-side reducing context-switches, and d) gets quite enjoyable once you know what you're doing. You obviously haven't written a lot of async code so not sure why you're so against the idea.

So again, to you, what benefit does everything being built on this async, single-threaded, event-driven model give you? Sounds like not much. You could get all of those benefits + much cleaner code using threading or fibers or actors, but that does not make for C10K badassness, so here we are, with our callbacks.

Also, I'd say I've written enough code on top of node.js to be qualified to comment on this. Here's some of it that's open source:

https://github.com/rbranson/glob-trie.js https://github.com/rbranson/twerk https://github.com/rbranson/node-ffi

Post reply on HN