Matt Aimonetti: Ruby in 2012
rubylearning.com
rubylearning.com
I'd recommend Matt just to dive deeper into Node, Express, Flatiron and all the 8,000 packages and he will discover tons of better solutions instead of sticking to the current status quo. And Node often feels faster, easier and less cumbersome than Ruby/Rails (once getting used to callbacks). I didn't mention performance which would be one reason to use Node—Matt wrote he would use it because being the new cool framework.
Ruby mainly exits because of Rails. Rails is the most automated web framework on earth, it's great and paved the way. We use both every day as first choice because of its maturity, the community, the high day rates we get, ten thousands of great gems seaming-less working together, the convention everybody knows.
Definitely Rails is the best full-blown solution for web development but real innovation happens somewhere else.
EDIT: disagree != downvote, reply if you disagree
Real innovation is language independent, and is certainly not defined by using the latest fad framework.
I disagree on your second point, languages drive innovation otherwise C/C++ would be sufficient for all of us. Anyway, let's not start a flamewar on languages, I like Rails using it myself.
Languages themselves are innovative, but I guess I don't see people using the language as the innovation there, but rather the creator and maintainer. More specifically I don't see my early adoption of Ruby as innovative.
No to the flamewars! I love Ruby and miss it every day (though C++ is growing on me).
If you're doing networking stuff, we've got EventMachine for doing event-driven architecture, and that's a heavily proven library in production.
Sinatra pioneered the microframework niche, and most microframeworks in other languages like node.js are almost a carbon copy.
And, of course, we have the highly mature full-blown frameworks like Rails, which is becoming more modular by the day. It's dead simple to pull out the default "cruft" that Rails comes with to make it easier for beginners and custom build your models, routing, controllers, templates, assets, etc.
I just don't see the appeal in switching to a less mature platform that doesn't have any benefits that I'm aware of.
All the Java devs and the Pythonistas were calling us late to the game and slow. The simple fact is, people enjoyed Rails more than what they had to offer at the time, so it grew and became what you see today. The fact that something is possible in two environments doesn't mean it's equally enjoyable in both. Never discount the impact that love can have on a project.
There's a big difference. EventMachine is an asynchronous library built with Ruby. EventMachine has nothing to do with Rails apart from them both being written in the same language. Now, go and try use both EventMachine and Rails in one project: it's a nightmare because they both follow different design principles. If you want to do event-driven architecture with EventMachine you will miss an ecosystem because a) there is none like around Rails and b) you cannot use Rails' ecosystem. Compare this to Node's ecosystem of 8,000 packages which follow all the event-driven architecture.
> ... that's a heavily proven library in production.
Heavily? Source?
> Sinatra pioneered the microframework niche, and most microframeworks in other languages like node.js are almost a carbon copy.
You are right and Sinatra was groundbreaking. But what's the goal of a microframework if the underlying stack is too complex for easy deployment or breaks with every patchlevel?
As for a source for the "heavy use in production" comment, I suppose I can't provide one off the top of my head. However, if you're a Rubyist you know how often Thin is used in production. For a while, it seemed like every deployment guide suggested the use of Thin cluster to run the app.
I'm not sure how you reached the conclusion that Sinatra (and thus, Rack apps, including Rails, in general) is difficult to deploy. We have mod_rails which makes it as easy as setting the apache DocumentRoot to your app. If that's not your cup of tea, it's a simple command to start up a cluster of Thin or Unicorn processes, and it's a few lines of nginx configuration to proxy. Essentially identical to how one would deploy node.js or any web development platform in existence for that matter.
* Ruby Core is a black box that produces tarballs. Point releases and even patchlevel releases will happily break code without warning. The only way to test if your code still runs is to run it, all of it. This is complicated by the fact that mod_rails cannot run each project on its own version of Rails.
* The professional Ruby world (=Rails scene) is a different beast. Most projects are open source, but linked to a single name (person or company). There is little incentive to maintain projects cooperatively, because if the project isn't yours, then how do you present it on your github-based resume?
* And then there are the hobbyists (with some overlap of course), many of which honestly cannot understand why some companies are still running 1.8.7 or Rails 2 and don't have their employees live on the edge all the time.
Add all these individually amazing but uncoordinated programmers together..and suddenly every line has to be prefixed by "bundle exec"; .rvmrc will specify your Ruby version, except if you use rbenv; your gemspec contains your dependencies, and so does your Gemfile (with subtle differences); your project info is spread across github, ruby-doc, ruby toolbox, rubygems and your own domain (to advertise yourself)...and often enough, the only documentation to guide you are blog entries, which sometimes omit the timestamp for stylistic reasons.
Ironically, the Rails Core - which gets the most flak by far - provides documented and tested fixes for each recent major and minor version of Rails.
Ruby code may have good maintainability but a Rails project doesn't.
It's a full-blown language, with a great community and great gems, and I don't see Ruby going anywhere in the near future.