3 ms·

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need. My expe

by jondot 14y ago

I am using a mix of Ruby, Node and Java in production but after some hard-learned lessons chose to minimize the Node usage to things I absolutely need. My experience with the Node community: - Great people (Substack!) - Great attitude #node.js/freenode - However, many hours spent on solving bugs in existing libraries. My experience with maintaining production Node code: - It may be more maintainable than EventMachine, but it's absolutely not more maintainable than Ruby. - V8 garbage collection is a real pain when you do work that needs it (this also includes memory held by open sockets). - Was V8 built for the server? (rhetorical) In the end, I prefer threaded Ruby code to evented Node code. I try to offset the inefficiencies of "threads vs evented" or "Ruby vs Node" by using the JVM and JRuby.

danenania 14y ago
It seems needlessly limiting to make EventMachine and Node your only candidates. Since you've already got java in the stack, what about clojure? What about go?
- jondot 14y ago
  I used the examples from the original article. I think the OP ported an EventMachine code to Node. When I said 'Java' I really meant JVM. Specifically I'm using Scala. Regardless, I have a different Clojure based project, with it as well, I prefer doing what clojure has to offer in terms of concurrency (pmap, etc). I have dipped a toe in Go. Loved the fact that you get a compiled binary, ecosystem still feels skinny. Ended up concluding that in a year or two it'll be worth revisiting.
  - continuations 14y ago
    If you're already using Scala, why do you need Node? What does Node give you that a Scala async framework like Play or Scalatra doesn't? Also what does Ruby give you that Scala doesn't? Just wondering why do you choose to use 3 stacks (Ruby, Scala, Node) when one could be enough.
    - jondot 14y ago
      I'll also try to address sandGordon's question. Like superfeeder, I have "backend" services, but I also have client-facing services. I value how Node.js handles slow clients. It also services some more 'utility' use cases for me, such as reverse proxies, etc. JRuby and Scala cover IO bound processing for me over the Web. JRuby covers the majority of the backend services. I use Scala coupled with Storm, and I could have used JRuby here too, but you can also use JRuby with Hadoop and you typically don't. Since this use case actually required the optimization (I wasn't prematurely optimizing), I went as bare metal as possible (ruled Java out, yes). Previously, this service was a Node.js service and got rewritten into Scala+Storm. I don't use Akka because I didn't feel it was needed yet. Old school threaded workers with JRuby works fine so far. I know that Scala is supposed to be a multi-layered solution and it can handle all of this. However, Ruby and Node brings the ecosystem Scala doesn't have (I'm not moved by the "but Java has a million Jars out there" argument, already integrating with them with JRuby). And in general Ruby makes me happy (SBT makes me very very angry and sad, for comparison - yet Scala is OK), that simple.
sandGorgon 14y ago
could you detail how you are using jruby to offset evented systems on node.js ? If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io
- jondot 14y ago
  >could you detail how you are using jruby to offset evented systems on node.js ? Simply because JRuby has real threads over MRI's GIL, and the JVM has a time-proven Server VM that has a very good JIT. I also leave open the option to drop to 'bare' Java. As the OP mentioned, it's a craft of balancing CPU and memory. In my case I don't mind the extra threads memory and context switching overhead. > If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io My Scala use case is with Storm, as mentioned in other reply. You can call that "backend" processing, instead of using it with a Web framework.

by jondot 14y ago

danenania 14y ago

It seems needlessly limiting to make EventMachine and Node your only candidates. Since you've already got java in the stack, what about clojure? What about go?

jondot 14y ago
I used the examples from the original article. I think the OP ported an EventMachine code to Node. When I said 'Java' I really meant JVM. Specifically I'm using Scala. Regardless, I have a different Clojure based project, with it as well, I prefer doing what clojure has to offer in terms of concurrency (pmap, etc). I have dipped a toe in Go. Loved the fact that you get a compiled binary, ecosystem still feels skinny. Ended up concluding that in a year or two it'll be worth revisiting.
- continuations 14y ago
  If you're already using Scala, why do you need Node? What does Node give you that a Scala async framework like Play or Scalatra doesn't? Also what does Ruby give you that Scala doesn't? Just wondering why do you choose to use 3 stacks (Ruby, Scala, Node) when one could be enough.
  - jondot 14y ago
    I'll also try to address sandGordon's question. Like superfeeder, I have "backend" services, but I also have client-facing services. I value how Node.js handles slow clients. It also services some more 'utility' use cases for me, such as reverse proxies, etc. JRuby and Scala cover IO bound processing for me over the Web. JRuby covers the majority of the backend services. I use Scala coupled with Storm, and I could have used JRuby here too, but you can also use JRuby with Hadoop and you typically don't. Since this use case actually required the optimization (I wasn't prematurely optimizing), I went as bare metal as possible (ruled Java out, yes). Previously, this service was a Node.js service and got rewritten into Scala+Storm. I don't use Akka because I didn't feel it was needed yet. Old school threaded workers with JRuby works fine so far. I know that Scala is supposed to be a multi-layered solution and it can handle all of this. However, Ruby and Node brings the ecosystem Scala doesn't have (I'm not moved by the "but Java has a million Jars out there" argument, already integrating with them with JRuby). And in general Ruby makes me happy (SBT makes me very very angry and sad, for comparison - yet Scala is OK), that simple.

sandGorgon 14y ago

could you detail how you are using jruby to offset evented systems on node.js ? If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io

jondot 14y ago
>could you detail how you are using jruby to offset evented systems on node.js ? Simply because JRuby has real threads over MRI's GIL, and the JVM has a time-proven Server VM that has a very good JIT. I also leave open the option to drop to 'bare' Java. As the OP mentioned, it's a craft of balancing CPU and memory. In my case I don't mind the extra threads memory and context switching overhead. > If you are using scala, which async framework are you using - I have heard it is basically scalatra vs spray.io My Scala use case is with Storm, as mentioned in other reply. You can call that "backend" processing, instead of using it with a Web framework.