The switch: Python to Node.js

Sounds like a weird reason to switch the language and framework used for your product. Blocking libraries block just the same in Node and in Twisted. Why not just stop using the Django ORM or more generally, stop writing code that blocks the main thread for long periods of time?<p>The problem of the main thread waiting on a response from the database is easily solved without rewriting all your code, which incidentally will have the same issues, since there's no new magic there.<p>If your software is a giant, ugly hairball because you wrote it in a hurry (I know I did this many times!) don't blame it on the language or framework. What I'm wondering is: Python/Twisted/Django rank equally or similarly on all the points from the list, except for Team Experience, which has to be much higher with the old stack than with a completely new technology and set of tools. This makes me think that there was a "play with shiny things" point after all.

I've come up with the same conclusion regarding the Django ORM, as they have. An excerpt:<p><i>I believe our single biggest mistake from a technical side was not reigning in our use Django ORM earlier in our applications life. We had Twisted services running huge Django ORM operations inside of the Twisted thread pool. It was very easy to get going, but as our services grew, not only was this not very performant, and it was extremely hard to debug</i><p>Django has in many ways become the industry standard in regards to fast development - but it, as so many other ORMs, does not scale and produces horrible SQL-statements. Also for many applications I find Django to be a huge overkill - and in more recent times I've focused a lot more energy using microframeworks such as Flask and Bottle.

Python is a programming language. Node.js is not. What you meant to say is that you switched from Python (presumably running on top of a Real Web Server) to javascript running on Node.<p>The argument could be made that they are both interpreters, but please, get it right - you are writing javascript, which is a pretty shitty language in which to develop apps these days. The only reason we use it is because it has near-universal browser support - and then only for UIs.<p>Also, not to parrot, but it's true - node is cancer. It's for fad chasers who have no idea how real servers manage to serve volume.<p>Fortunately, most people inexperienced enough to choose node are inexperienced enough to never need to scale, so it'll work out okay for them - for implementation-specific values of 'okay'. :)

I blame them and not the technology stack they used. It's idiotic to mix blocking technologies with non-blocking technologies as blocking the IO loop is fatal for performance as you won't be able to process any events while the IO loop is blocked.<p>And this person still has not learned from their mistake, they think that using SQLAlchemy would have solved their problem. If they wanted to make Twisted work they should have picked a database that can be used in a non-blocking way.<p>The reason why I like node.js is that everything is built in a non-blocking way. Twisted has the same philosophy until people think they can get away using a blocking library inside the IO loop.

The depth of libraries available in the Python or JVM ecosystems is going to dwarf what's available for Node. Were you able to find everything you need for Node?

so what makes javascript callbacks easier to understand than twisted's deferreds? aren't they basically the same thing?<p>and how does "we picked Node.js" logically follow from "It is obvious that the JVM platform is one of the best ways to build large distributed systems right now"?

If they believe in Node.JS, good for them. I assume they have the right people to write good and modular javascript code.<p>If you're a good front-end JS developers but never ever wrote a minimum reusable JS library, you've got a lot to learn before diving to JS.<p>As long as the code is waaay more modular than this: <a href="https://github.com/marijnh/CodeMirror2/blob/master/lib/codemirror.js" rel="nofollow">https://github.com/marijnh/CodeMirror2/blob/master/lib/codem...</a><p>They should be alright in terms of adding new features. And if Node.JS hits scalability issue? well tough luck I suppose.<p>I see that JVM is a very serious contender but as already noted: License issue. And let me add this: I'm betting my ass that there's the "I don't want to write Java" whisperers as well. Now now, don't BS me. I know how the so-called "engineers" think of Java these days. Sure, you could use Clojure, Scala, or JRuby. But seeing the competitor is Node.JS, pretty easy choice don't you think?<p>My experience writing JS code for Node.JS based platform (ExpressJS, etc) is that there's a bigger chance that you'll write more code. Code to make the code more modular (sounds weird isn't it?). Code to make sure you work-around the warts of JS. Each line of code should be highly scrutinized due to JS warts.<p>This thread is going to be a typical fun nerds-fight. I guarantee you. I'm going to grab a popcorn and watch nerds doing keyboard slamming.

I'd really like to see that spreadsheet, since there are many python frameworks other than twisted available. There are eventlets/greenlets, there's gevent, there's diesel and monocle for minimal things, etc. Makes you wonder what actually made them change the whole technology... Than again, they could probably even reuse pyjamas to still write node.js code in python...<p>OT: "We should of used SQLAlchemy. We should of built ..." I thought this expression was Bristol-specific. Apparently it's taking US too.

If you want to use a reactor pattern and you don’t want to use JavaScript, you can use EventMachine on Ruby. Twisted is the same thing for Python. I’m sorry to hear you were having problems with Twisted, but EventMachine is absolutely rock solid. I have gotten a lot of work done with it.<p>Now, let’s say you don’t want to do callbacks, but still take advantage of the Reactor pattern in EM. I wrote a patch for Sinatra that uses Fibers to wrap callbacks, hence allowing you to continue to program synchronously as you used to, and it’s called Sinatra Synchrony (<a href="http://kyledrake.net/sinatra-synchrony" rel="nofollow">http://kyledrake.net/sinatra-synchrony</a>).<p>But in order to do non-blocking IO, you don’t need to use a Reactor pattern, because Ruby internally does not block on IO (the GIL does not affect this). And of course you get solutions like JRuby (built on the JVM), which provide for threads (and Rubinius 2 coming soon).<p>My APIs written with any and all of these concurrency options can get thousands of hits per second. It’s quite scalable, but still provides all the rich libraries, reusable code, and testing support that makes my APIs high quality, which to me (and my users) is more important than making them fast. With this approach, my APIs are both high quality and fast. And I have never experienced a single crash of any worker processes in production. I would know, because my process monitor is smart enough to observe the workers in my deploy code and informs me, while adding another worker to replace the fallen one. Did I mention I can do zero-downtime hot deploys? Again, all implemented in Ruby.<p>I’m not trying to brag here, but there’s this weird current of arguments that these existing solutions don’t scale. It’s a myth, I don’t know where it comes from, and I’m worried that if I don’t speak out against these arguments, I’m going to wake up in a giant pile of half-baked Javascript spaghetti written by people that didn’t even understand the real problem in the first place (blocking IO people, research it!).

After developing a v1.0 of a project with django i ended up also moving to node.js as well as mongodb as opposed to postgresql. I found myself increasingly wrestling with django. I really like python and the django community and think django is good for certain types of applications. But at least for what im building it wasnt the right solution. Im also using node.js for another project which is also currently built with django. It has different requirements and i might use python on the backend whereas the other project will most likely just be node.js and mongodb.

I'm curious as to why Go wasn't a final contender? It started off with Go being a crowd favorite and ended with it nowhere. I assume it has to do with the young package repository but what's the reasoning you used?

Did you evaluate EventMachine? If yes would you please share your findings.