Live data from Hacker News

Why we moved from NodeJS to Ruby on Rails

blog.targeterapp.com

151–160 of 166 posts

Re: Why we moved from NodeJS to Ruby on Rails

#151

Earlier quoted context omitted.

Only rookies do that inside the web server process. The job of fetching a Twitter feed can be offloaded to a background jobs queue. With a little help from Nginx, you can free the Ruby process to take care of other requests until the response of that Twitter feed is ready. Or you could simply deploy your Rails app on top of a Java server, by means of JRuby and forward that request to a servlet that uses the continuat…

Rails does work with multi-threading. Ruby has no support for concurrency, no matter how many threads your interpreter is using. 1.8 had no OS threads at all, and 1.9 has a global interpreter lock. This is not solvable in the application layer (for example, by a framework like Rails): this is a problem inherent to the runtime.

JRuby is fully parallel with no global lock and many people choose it for deployment. Rubinius 2.0, which is in development, will also lack the GIL.

You're also very confused about how threading on Ruby MRI 1.9 works. First of all, pure Ruby code in 1.9 can and does execute on multiple OS threads, in parallel.

Also, the problem that the Ruby VM still has is that while executing native code, it does not allow a context switch unless that code explicitly informs the VM that it can do a context switch. This is in effect how the global interpreter lock works. The gotcha here is that native extensions that are well behaved, can inform the VM that a context switch is possible. For instance, the older "mysql" gem was NOT well behaved, blocking context switches between threads, but the newer mysql2 gem does behave well and works correctly in multi-threading.

Right now, if you start a new Rails 3 app, it will work in a multi-threading environment correctly and modern Rails servers are taking advantage of that, unless you install some older gems that haven't been fixed. The biggest problem is that you can't know what libraries are well behaved, but if that's too much of a burden, JRuby is a fully supported platform for Rails and doesn't share the same issue.

So like, seriously dude, do some reading.

Re: Why we moved from NodeJS to Ruby on Rails

#152

Earlier quoted context omitted.

Only the CLI utility in Play used Python, and the newest version has replaced this dependency with Scala/SBT instead. I imagine the original reason for using Python for the CLI was because it's pretty damn easy to do that in Python.

Python is great for that sort of thing - but there do exist CLI helper libraries for Java in Apache Commons that make it almost as nice. It's just wierd to me to make development tooling for a langage in a different language - and indeed, if you find yourself doing this you might want to ask yourself why. (Of course there's a clear market reason - the hosted Ruby on Rails market is locked up by Heroku, but the hosted…

If you have to ask yourself that question, then you haven't really worked with a scripting language like Python or Ruby.

Re: Why we moved from NodeJS to Ruby on Rails

#153
post #62

Earlier quoted context omitted.

There's also mocha: http://visionmedia.github.com/mocha/ Which has very similar syntax to RSpec.

Try writing tests for controllers with Mocha. It isn't as simple as one might think.

Can you elaborate? I feel that I've written tests for controllers with Mocha several times without much hassle. Maybe you and I are using the word "controller" slightly differently, or are controlling different things?

Re: Why we moved from NodeJS to Ruby on Rails

#154
Ok. So for a beginner coder looking to build web sites and mobile apps on weekends. They are not looking for a career or job coding. What language?

Assume they know html, CSS, Javascript, SQL. Where do they go and spend their next 12 months?

When do the differences matter?

Re: Why we moved from NodeJS to Ruby on Rails

#155
post #70

Wow, Node is being turned away from because it's too new, and Rails is the destination because it's established? I remember a few years ago Rails using the argument of re-inventing the wheel was the only way because there was presumably no other capable web framework out there. We all know better now and I hope celebrate choice that's relatively equally capable :)

And people switched away from Rails back then too :-) http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...

Is this article from 5 years still relevant?

I know you said 'back then' but curious to know whether one should stick with php.

Re: Why we moved from NodeJS to Ruby on Rails

#156
It saddens me that so many developers need to learn why it's a mistake to build a system in node.js right now, just because it's "cool" right now. A variation of this post showed up on HN about 20 times already.

The lesson is simple - don't use node.js to build big apps, it's still immature.

Re: Why we moved from NodeJS to Ruby on Rails

#157
post #25

> NodeJS is suitable for apps that do plenty of short lived requests. I'm confused. Isn't Node's event-loop style programming ideal for long-lived requests? I.e. ones that, under a synchronous i/o, block other requests?

"short lived" probably means that the business logic is lean.

Re: Why we moved from NodeJS to Ruby on Rails

#158
post #153
post #62

Earlier quoted context omitted.

Try writing tests for controllers with Mocha. It isn't as simple as one might think.

Can you elaborate? I feel that I've written tests for controllers with Mocha several times without much hassle. Maybe you and I are using the word "controller" slightly differently, or are controlling different things?

My apologies I wasn't too specific. I was meaning a controller through express. It's not as straightforward as you would expect with code buried throughout on how to set it up. This is a typical barrier for developers to not test as much.

Re: Why we moved from NodeJS to Ruby on Rails

#159
post #158
post #153

Earlier quoted context omitted.

Can you elaborate? I feel that I've written tests for controllers with Mocha several times without much hassle. Maybe you and I are using the word "controller" slightly differently, or are controlling different things?

My apologies I wasn't too specific. I was meaning a controller through express. It's not as straightforward as you would expect with code buried throughout on how to set it up. This is a typical barrier for developers to not test as much.

Express doesn't even have controllers though -- just a routing mechanism.

If you set up your controllers so that they are independent from the routes, then they are just as easy to test.

It could be as simple as: app.get('/users/:id', userController.userPage). You can then test userController.userPage(req, res, next) instead of the route.

Re: Why we moved from NodeJS to Ruby on Rails

#160

Earlier quoted context omitted.

And people switched away from Rails back then too :-) http://www.oreillynet.com/ruby/blog/2007/09/7_reasons_i_swit...

Is this article from 5 years still relevant? I know you said 'back then' but curious to know whether one should stick with php.

Yes/no/it depends - pick an answer :)

I believe Derek kinda went back on this answer a bit and ended up taking up Rails again later on, but the issues regarding PHP being more practical and flexible for him at the time were pretty important. These issues will still be relevant for many developers and even as a Rubyist myself, I'd say Rails is certainly not the right choice for everyone.

Post reply on HN