Live data from Hacker News

Is NodeJS Wrong?

ncannasse.fr

21–30 of 47 posts

Re: Is NodeJS Wrong?

#21
post #15

Earlier quoted context omitted.

To me, it seems the real weakness of node.js is having to manage asynchronous control flow yourself, at all . It grows exponentially more ugly as the system increases in size. I really like continuation-passing-style as a technique (especially as a compiler IR), but doing that stuff by hand is so 70s . I got pretty far along writing a similar system in Lua (because, hey, event-driven systems are pretty nice), and unl…

Thanks for this, you've nailed the problem. I'm looking for a language that can do everything that Node.js does but also solves this control flow problem, but is also fast and has support for OpenCL and beefy math libraries. I don't find Erlang to be performant in this regard, so I'm looking at Scala but I'm constantly getting pissed.at.java.packages.and.conventions. I think it also suffers from the same problems as…

Take a look at LuaJIT.

I have some early FFI bindings for OpenCL (and OpenGL, glfw) with some simple demos. Not updated recently, but it's done by using stock luajit (take latest), and not writing a binding code at all (just FFI definitions which LuaJIT understands).

You can't do callbacks (yet). That is - you can't rely on "C" function to call you back at lua land. That's why I chose glfw instead of glut or others. There is way to setup your main loop without callbacks.

http://github.com/malkia/luajit-opencl

Re: Is NodeJS Wrong?

#22
post #8

Given any long-running task, there are two natural things to do: 1. Do something while the long-running task is running 2. Do something after the long-running task has completed Node.js' callback function convention simply makes it stupendously easy for you to write code for both cases, and leans towards making case (1) as natural as possible. Case (2) is naturally easy in Javascript (and even easier in Coffeescript)…

To me, it seems the real weakness of node.js is having to manage asynchronous control flow yourself, at all . It grows exponentially more ugly as the system increases in size. I really like continuation-passing-style as a technique (especially as a compiler IR), but doing that stuff by hand is so 70s . I got pretty far along writing a similar system in Lua (because, hey, event-driven systems are pretty nice), and unl…

  > Still, most libraries are blocking*
  > * Which is a funny objection, like being 
  > mad that most libraries default to using
  > decimal numbers rather than octal. It must
  > be a conspiracy!
Actually, there _is_ a distinction here: It is ridiculously easy to implement blocking semantics on top of non-blocking semantics - in some pseudo code:

  event = do_async();
  pause_until_completion_or_error(event)
Whereas implementing non-blocking semantics using an underlying blocking implementation is quite, but not entirely, like banging your head against the wall. repeatedly. Essentially, you cannot avoid threads, shared mutable state, and a lot of other problems.

Re: Is NodeJS Wrong?

#23
post #18
post #5

Several commenters point out that long-running computations can be performed outside the main request thread without the server having to do anything special. It's also possible to divide up long-running computations oneself. This can lead to very interesting designs.

"Several commenters point out that long-running computations can be performed outside the main request thread without the server having to do anything special." Then why am I using Node.js? Any language has been able to do that for over a decade now, without the other hoops Node.js's style forces you to jump through. As evil and bad as shared-state multithreading truly is, this is a (or possibly "the") task it can ma…

I don't really understand your comment.

No one's saying that IPC is unique to Node. The OP's criticism was: async i/o is fine, but what if you have some CPU-intensive work to do? Isn't it bad to let that block the whole server? Of course it is. OP's answer is a different server architecture; Nodians' answer is just forward that work to a different process and let Node keep doing the one thing it does well.

Why use Node? Isn't the reason that it lets you write server apps that don't block on i/o, in a high-level language?

From various comments over the last year or so, I gather that you're saying Erlang beats Node hands down at this. That may be true. Still, not everyone's going to use Erlang. What other alternatives are there? (Twisted, EventMachine, ...?)

I can see the attraction of Node's approach. First, it's conceptually simple. Second, yes, it shoves a bunch of things in your face and makes you deal with them - but they are precisely the things that make your program slow. Perhaps you want to deal with them. I can understand why someone would say: I want to manage my program's control flow explicitly so I know it won't block when it shouldn't; it makes some things annoying, but other things easier (at least I don't have to worry about other code interrupting mine); just don't make me write everything in C.

(At risk of being tedious, I'll add that I'm not being polemical. You, silentb and others know a lot more about it than I do. I'd like to get clearer about what the issues are. Also... I'm tempted to reply to the second part -- about writing programs that know how to divide up their computations, and whether this is greenspunning the OS -- but this is long. Maybe we should defer it.)

Re: Is NodeJS Wrong?

#24
post #15

Earlier quoted context omitted.

To me, it seems the real weakness of node.js is having to manage asynchronous control flow yourself, at all . It grows exponentially more ugly as the system increases in size. I really like continuation-passing-style as a technique (especially as a compiler IR), but doing that stuff by hand is so 70s . I got pretty far along writing a similar system in Lua (because, hey, event-driven systems are pretty nice), and unl…

Thanks for this, you've nailed the problem. I'm looking for a language that can do everything that Node.js does but also solves this control flow problem, but is also fast and has support for OpenCL and beefy math libraries. I don't find Erlang to be performant in this regard, so I'm looking at Scala but I'm constantly getting pissed.at.java.packages.and.conventions. I think it also suffers from the same problems as…

Perhaps you could try python, numpy, twisted, inline callbacks and one of the python opencl packages.

Inline callbacks are syntactic sugar included recent versions of twisted that make your code look synchronous while still running on the event loop.

With python, you get to use a wealth of libraries, but you need to still be mindful of what is blocking.

Wnen something you need to call is blocking, you can try deferToThread.

Don't worry, you won't need to think too much about race conditions and other concurrency issues with threading since there is the GIL in python. Also, Twisted makes it a cinch.

Good luck!

Re: Is NodeJS Wrong?

#25
post #15

Earlier quoted context omitted.

To me, it seems the real weakness of node.js is having to manage asynchronous control flow yourself, at all . It grows exponentially more ugly as the system increases in size. I really like continuation-passing-style as a technique (especially as a compiler IR), but doing that stuff by hand is so 70s . I got pretty far along writing a similar system in Lua (because, hey, event-driven systems are pretty nice), and unl…

Thanks for this, you've nailed the problem. I'm looking for a language that can do everything that Node.js does but also solves this control flow problem, but is also fast and has support for OpenCL and beefy math libraries. I don't find Erlang to be performant in this regard, so I'm looking at Scala but I'm constantly getting pissed.at.java.packages.and.conventions. I think it also suffers from the same problems as…

Haskell (or rather GHC) offers a blocking programming model (e.g. spawn a thread per connection and make blocking reads/writes on the socket) but uses asynchronous I/O in its implementation (one thread uses epoll/kqueue/poll to do the I/O and the CPU bound threads are scheduled on a thread pool).

Re: Is NodeJS Wrong?

#28
post #23
post #18

Earlier quoted context omitted.

"Several commenters point out that long-running computations can be performed outside the main request thread without the server having to do anything special." Then why am I using Node.js? Any language has been able to do that for over a decade now, without the other hoops Node.js's style forces you to jump through. As evil and bad as shared-state multithreading truly is, this is a (or possibly "the") task it can ma…

I don't really understand your comment. No one's saying that IPC is unique to Node. The OP's criticism was: async i/o is fine, but what if you have some CPU-intensive work to do? Isn't it bad to let that block the whole server? Of course it is. OP's answer is a different server architecture; Nodians' answer is just forward that work to a different process and let Node keep doing the one thing it does well. Why use No…

What other alternatives are there? (Twisted, EventMachine, ...?)

Lots, depending on what you're doing: scala actors, akka, STM in haskell and clojure, GHC (lightweight) thread manager, F# async's and MailboxProcessor; apple GCD; Microsoft Message Queuing (MSMQ),Completion Ports. ZeroMQ, rabbitMQ/AMQP

(but you should spend some time looking at erlang)

Re: Is NodeJS Wrong?

#29
post #21
post #15

Earlier quoted context omitted.

Thanks for this, you've nailed the problem. I'm looking for a language that can do everything that Node.js does but also solves this control flow problem, but is also fast and has support for OpenCL and beefy math libraries. I don't find Erlang to be performant in this regard, so I'm looking at Scala but I'm constantly getting pissed.at.java.packages.and.conventions. I think it also suffers from the same problems as…

Take a look at LuaJIT. I have some early FFI bindings for OpenCL (and OpenGL, glfw) with some simple demos. Not updated recently, but it's done by using stock luajit (take latest), and not writing a binding code at all (just FFI definitions which LuaJIT understands). You can't do callbacks (yet). That is - you can't rely on "C" function to call you back at lua land. That's why I chose glfw instead of glut or others.…

There is also a coroutine based embedding of Lua/Luajit in nginx if you want to embed into a web server environment (without callbacks). https://github.com/chaoslawful/lua-nginx-module

Re: Is NodeJS Wrong?

#30

This is a bit annoying since if you want to make three async requests you have to write the following Well, beyond a style issue. You can unfold the events and make it a lot less "annoying". Consider, var cb1 = function() { } var cb2 = function() { req(cb1); } var cb3 = function() { req(cb2); } req(cb3); It's a lot cleaner and it looks like a state machine (and kind of looks like erlang/message passing).

I've actually been put off Node a little because I've not seen any examples using this style of code. I had (perhaps stupidly) assumed that the scope of a closure was necessary for a lot of Node functionality; generally speaking, are all the parameters required for interacting with Node passed via the function parameters?
Post reply on HN