Does anybody else get a little question mark over their head whenever they read about the "novelty" of being able to use javascript on the server?
Certainly everybody must remember ASP, which let you write all your server-side code in Javascript way back in 1998. You can still do it today, even in ASP.NET MVC.
And just like Node, nobody ever really shared much rendering code between the client and the server using that technology either.
"The Ruby community has been criticized for being exclusive and harsh."
I haven't found that to be the case at all, unless you're asking questions that are easily solvable with a quick Google search (and that mostly stems from the flood of inane questions from Indian "programmer mill" graduates).
Node's community also benefits from the fact that a lot of people are still trying to wrap their heads around events and callbacks, so they naturally help each other through the process.
I was always baffled by this, but I from what I have read recently it seems to be a confusion between 'end-user' developers and 'ecosystem' developers.
End-user developers who only use ruby/rails/etc to build things, for work or whatever, operate on another plane from the developers of rails itself and various associated libraries.
Members of the first group generally do not need to come into contact with the machinations of the core ruby community for a long time, so we can be left a little baffled at first by these accusations of 'harshness,' all the other hackers who answer our questions on stackoverflow and write helpful instructional blog posts seem really nice!
Then eventually you read various IRC logs, mailing lists and personal blog posts by various members of project teams and certain notorious hero developers, and you realise where the accusations stem from. It doesn't seem as bad now as it was in the Rails 2 vs. Merb days however.
The most important thing for bystanders to realise however is that these criticisms of the ruby community do not actually have anything to do with the 'end-user' developers who you will be dealing with as peers on a day to day basis if you are writing a ruby project that isn't a library.
Anyway I've remembered that this thread is actually about node so I'll shut up and have breakfast.
See, that's just it. Rails is a different "community" than Ruby. And, as someone who has worked with both the better part of 5 years, I've found Ruby very open and welcoming while Rails less so.
I take more issue with Jolie's unsubstantiated remark about "the Ruby community". She casts a whole group of people in a disparaging light and doesn't been take the time to source it.
I'm baffled by the fact that an article about why Node.js is popular contains so many overtones of a Ruby/RoR takedown piece. I'm trying not to be defensive (Ruby/RoR are my language and platform of choice), but the constant us of Ruby and RoR in analogies where they play the bad guy kind of has me feeling a since of irony.
"The Ruby community has been criticized for being exclusive and harsh," says the person using the Ruby community as the fall guy to prop up the new, exciting kid on the block. Are the feelings of exclusivity in the Ruby/Rails community not in some way tied to the prevailing attitude toward other languages? cough PHP
Clarification: I don't mean the above to be a slight against PHP. I'm simply pointing out that a lot of the negativity in the Ruby community centers around snobbery toward other languages, and PHP often takes the hit... hence the irony here.
Ruby and Rails are inextricably linked, because that's how a lot of people get into Ruby, and Rails is by far the most "visible" Ruby project. Plus, Rubyists are the new Pythonistas are the new Perl(issimos?) are the new Lispers.
It's more like "Everyone is talking less about Rails" - the only new kid in Rails block is Haml/Sass and Rails is obviously stagnating compared to the hype it had couple or more years ago. Ruby/RoR is more about evolution now: Rubinius, JRuby going for stability, SalesForce adopts Heroku as one of it's development platforms - look, even one of Big 4(DTT) hires RoR-consultants now.
JavaScript on the other hand is booming both on client (SproutCore, Backbone, Cappuccino, CoffeeScript, GWT) and on server (Node). JS is just more "hackish" today - browsers are evolving day-by-day, taking more and more functionality from server - RoR isn't key to success anymore, it has become just another alternative for your REST backend.
Not sure it's fair to say Rails is stagnating. Rails 3 (particularly with the improvements in ActiveRecord) is significantly leaner and nicer to use than Rails 2.
"stagnating __compared to the hype it had couple or more years ago__"
New API for ActiveRecord, modularity, merging with Merb are very important, but it's not a game-changer. Rubinius and RubyMine on the other side are game-changers.
I welcome the stagnation! We started development with Rails when it was at 0.7, and the pain of keeping up with a rapidly developing framework was something I felt some level of resentment for.
I wouldn't say Rails is stagnating, I'd say it is maturing.
For me it's about simplicity. RoR has become a beast almost of asp.net/IIS proportions. I'd rather not deal with the hassle of getting everything set up. That's why I'm in love with Sinatra, Node, and golang.
Im not sold on node. Why should i ristrict myself? There are async librarys in lots of languages you can use them if you have a problem that suits the async modle but you can use other models to if they are better.
The other thing with node is that it is single threaded do do multicore you have to use process witch are slow in communicating. This could work now because we often only use quadcores but in the next years we will have many many more. Is it a solution to start node up for say 16, 80 or 1000 cores?
Im not ranting on node I hear it works fine for some stuff but the benchmarks that got everybody so exited in the beginning was not really that practical.
If I write a low level it might be fast because it maps to the C stuff good but if I write a big application with lots of layers of JS will it still be fast? (I know that V8 is getting better but it there jet for big server applications?).
Why Everyone Is Talking About Node: The very smart guys at Joyent are packaging it and pitching it perfectly.
The mobile platform has been gaining steam and so real-time interaction is becoming more important. Joyent was smart enough to see this & find a way to put their current infrastructure (lots and lots of invested $$) right into the middle of this. Node is well packaged as a solution to this. Very smart.
No doubt Node is the right solution for a lot of problems. And the guys working on it are very smart. But personally, I think that Node and Erlang compare somewhat like Lisp and C. At least at this point...
Actually, I meant it the other way around; what's popular isn't necessarily what's better.
I personally like coding in Erlang more than JS. I also personally feel the smart technology choice is Erlang -- it scales better. For me, Erlang is an easy choice, but I know that other people have different priorities that make Node the right choice.
I believe that the biggest thing holding Erlang back in this role is the fact that it's functional rather than imperative & that the syntax isn't C like. It's a complexity that many don't find worth the trouble.
I think the main thing holding erlang back is its community culture, its source may have been open, but it was not an "open source" project until very recently, some might say it still isnt, the good news is that it is changing.
The OTP team moved erlang to github so people can see and contribute to its development.
The OTP team are moving erlangs infrastructure to open tools (the tests are switching to common test) which helps outside contribution a lot.
Community contributions are starting to pick up, http://erlagner.org/ is finally a package manager that has been picked up by the community, http://learnyousomeerlang.com/ is an awesome set of beginner tutorials, http://erldocs.com/ (mine) is an easy way to browse the documentation.
Node is a lot younger but is already more mature than erlang in all the areas above, erlang is playing catch up in these regards, but it has a much more solid base.
I'm not saying anything (pos or negative) about node.js, but regarding erlang syntax, i'll make (circumstantial) arguments that erlang really is not complex:
- the pattern matching syntax of erlang, F#, ocaml and haskell is similar (obviously the 4 differ in a lot of details, but it's getting harder to avoid all 4 langs round these parts (HN)
- I don't have the stats in front of me, but if you look at LoC counts for the erlang killer apps (rabbitMQ, CouchDB, riak the dynamo clone, ejabberd etc) I think you'll see that the core functionality is usually a small number of thousands rather than 10K's of LoC.
(Looking for LoC stats, ohloh doesn't back me up, they show e.g. 180k for ejabberd, 18k for riak ... where the heck are LoC stats in github?
Love this comment:
"I'm still firmly convinced this recent enamour with node.js and particularly with the javascript programming language is the single biggest case of Stockholm syndrome ever."
http://mashable.com/2011/03/10/node-js/#comment-163390713
It seems to be a manifestation of the press’s—and humanity’s, I suppose—catty rage to see a conflict wherever there is a difference of opinion. I’ve never heard anyone compare Node to RoR except in terms of their communities, or the buzz surrounding them. They're different tools for different jobs, and the article grudgingly acknowledges that everyone seems to understand this.
In other words, I tried to make it interesting to a technical audience but still comprehensible to the average reader. I'm working on a more technical "how to get started with Node" post with code samples; that should be up in a couple weeks.
"It allocates web server resources on an as-needed basis, not pre-allocating a large chunk of resources for each user. For example, Apache might assign 8MB to a user, while Node assigns 8KB"
What? Apache may allocate 8MB of stack space for each thread, but that doesn't mean it consumes that much memory. This is distorting facts.
Where does the author get the idea that JavaScript is easy? As a Ruby and Node developer, JS is much harder. Fewer libraries, less syntactic sugar (e.g. 3.hours.ago, 3.times) and a prototype object system.
and they can be implemented almost identically in Javascript (just use 3.hours().ago() - each one can return a useful value, and have helper methods just like Ruby.)
although 3.times is probably harder since all ruby methods take an implicit block as last parameter. The prettiest code you could do in node would be 3.times(function(){/code/})
It would be nice if js could rid of the keyword 'function' -- maybe make it a bit shorter like in coffeescript.
"function" will be gone soon enough - replaced (ok, augmented) in the next version of JS with "#" - so you'll be able to write: #(x) { x * x } instead of function(x){ return x * x; }
If you're into Node.js and Redis we (Voxer, interviewed in the article) are actually hiring engineers. We're building a Walkie Talkie for iPhone and Android.
In more technical terms Voxer is a low latency messaging system for voice, images, and text. We have an iOS client in the App Store, and an Android version is in the works. We've had explosive growth in the last couple of weeks and are now in top 25 in a bunch of app stores and we are looking for someone to help us develop the server side components and make the system scale.
Email me gustaf@voxer.com if you want to know more and I'll connect you with the right person.
Our servers are built out of Node.js, CouchDB, and Redis. If you are excited about node, server-side JavaScript, and new databases, this is an opportunity to work on this technology full-time.
A misunderstanding of the technology is also a risk. Former Twitter engineer Alex Payne’s claim that Ruby was slow continues to haunt general conversations about Ruby to this day
The more things change, the more they stay the same! Chatter about slow will hang on even when the facts contradict.
I find it hilarious that people STILL criticise scripting languages for being slow. I mostly build sites in PHP - it's not a great language, it's not a fast language, but it really doesn't matter - page loads bottleneck on DB or front-end long before PHP's execution time becomes a problem, even without an opcode cache!
What I find fascinating about node.js is that it is one of a long chain of products that represent the constant repackaging of old ideas - with better results.
Twisted has been around for a long time and was the best (IMO) platform for building real time apps. Many of the first great comet apps were built on twisted. But you really have to work at using twisted - the docs aren't great, the reactor / deferred patterns take some time getting used to, and finally and most importantly the community isn't effective in evangelizing their product (sorry Glyph)
Another issue seems to be timing. Low latency apps have a current buzz and you see people rediscovering old collaborative ideas like Push to talk (referenced in the article). I wish them luck - PTT has failed spectacularly in the past but maybe will have a strong second life in a world full of smartphones. Node.js seems to riding this wave - and the backers leveraging the buzz to drive interest in the platform.
I also wonder if location is an issue. The Twisted team had a strong core in Boston while the Node interest seems to be coming out of the valley - and leveraging that environment's idea pressure cooker.
It also seems that node.js would benefit from a good implementation of the generator pattern that would enable you to write asynchronous code in a (somewhat) iterative style. Unfortunately I don't think that V8 implements any of the ecmascript extensions pioneered by Mozilla that implement yield, list comprehensions, and other fun stuff.
Thanks to Mongrel2 you can do real time in Ruby too or with the language you happen to like the most or for which you have the right "business logic" libraries.
Having code in production running both NodeJS and Mongrel2, I am happy to see both of them growing.
Please, look it up. From wikipedia: "A system is said to be real-time if the total correctness of an operation depends not only upon its logical correctness, but also upon the time in which it is performed."
FWIW, the author of the article said that she's going to do a little more investigating and likely change the language she used about the Ruby community.
Why do people cheering for new web technologies like to spread FUD against Ruby/Rails?
From the article, Ruby developers are assholes, Rails doesn't scale (for an umpteen time) and Ruby has high barrier of entry compared to Javascript (I don't know what does this even mean).
Perhaps it's because FUD drives involvement by creating division. Humans seem to love to disagree so building up an article based on random unprovable opinions usually gets people riled up and responding. It's link bait, essentially.
I haven't used node.js yet, so I can't speak for or against it. If I find a use for it I'll probably give it a try. If it doesn't feel right I can always use EventMachine in Ruby, use Erlang, Python or whatever else makes sense.
I'm confused by the statement that "only one company came out of rails rumble". I freelance for a startup that has a profitable SaaS app that was born at rails rumble 2007.
You would think a Rackspace sponsored article about Node.js would mention Nodejitsu, a Node.js hosting company built on top of the Rackspace cloud which has created Node.js libraries for Rackspace's cloud apis.
This is my first time posting here. The article is sponsored by Rackspace and I do not know any other companies which are using Rackspace and Node.js. I'm interested in this area of discussion and would like to know if anyone else is using the Rackspace cloud and Node.js. I'd also be interested in knowing other ways Node.js can be setup to work with Rackspace servers. Any additional information would be much appreciated, thank you.
Certainly everybody must remember ASP, which let you write all your server-side code in Javascript way back in 1998. You can still do it today, even in ASP.NET MVC.
And just like Node, nobody ever really shared much rendering code between the client and the server using that technology either.