I finally pushed through but I suspect just getting things running is a big enough PITA to deter new people from participating in Ruby land. Even if Hannson says it's a myth.
In languages like PHP, it's possible (again, this is becoming less common) to run an ad-hoc PHP application by simply requesting the URL to the file. For example:
* Drop myapp.php in to your httpd doc root
* Request http://myserver.tld/myapp.php
* Great success!
Rails doesn't work this way at all, and I don't know of an equivalent in the Ruby ecosystem. There is ERB, but no one runs a bare server that just maps myapp.rb to a URL; e.g., http://myserver.tld/myapp.rb. There's always some sort of router in between. Sinatra is probably the most basic Ruby app framework in common use and it still has a router. There are good reasons for this. In Ruby, everything is an object, so if you're writing good Ruby code, you need a way to map URLs to your objects.
Rails is somewhere between Java and mod_php in terms of application infrastructure complexity. The most important distinction is that you have an app server that is separate from your web server, and you have to do, at least, some basic configuration (even with Passenger). Many PHP devs never put any thought in to their server stack. PHP is part of their base Apache install on whatever shared host they're using, and everything "just works".
I'm trying really hard not to paint PHP devs in a bad light. All of this arrises from the circumstances you "grow up" in. There are plenty of PHP stacks that distinguish app worker processes from the web server, so please understand I'm not claiming some kind of superiority. To the contrary, the Ruby community recognizes the complexity penalty taken here, and is making efforts to develop easier ways to jump in to Ruby on Rails development.
This seems like a good topic for a blog post. I might write something up.
Available for free online, though you can also pay for it if you'd like.
As a beginner, trying to deploying a rails app to production from scratch is likely to drive you a bit crazy.
One problem is that their deb package doesn't specify ruby as a dependency. Another problem is that you have to examine their inlined bash install script to get to the .deb package to diagnose that. Another problem was that ubuntu's standard package repositories didn't include the version of ruby they needed (ruby1.9.1 - though I just checked now, and it seems to be available again). So I installed rvm, suggested by www.ruby-lang.org as an easy route, which needed me to install a whole bunch of other stuff, and finally installed the latest version of ruby - but this was too recent for their package to accept. sigh Eventually I found an old, undocumented gem of theirs that would install their command-line tool (well, half of it anyway). Maybe it's seamless if you already have ruby installed - but it's a terrible way to start ruby, in my experience anyway. Possibly it's more streamlined on Windows/Mac.
Then... all three versions of ruby that I tried (1.8, 1.9.1, 1.9.3) had changes that broke my tiny toy code. So astonishing, I'm not even mad.
Look at Python, with 5-year support for Python 2 before breaking compatibility with Python 3. And Java, well, I've never heard of code being broken (assert could have, but never heard it happen).
Ruby is labour-intensive - that's the price of constant (incompatible) improvement. Part of that price is documentation that goes out of date, instructions that go out of date, code that goes out of date. It becomes unrealistic to invest in Ruby - unless you plan to be working intensively on it anyway. Which I think does make sense for its original professional users, who are constantly iterating anyway. But it's not good for people who missed the early wave, when ruby was friendly.
It's a shame, because there's a lot of cool ideas in ruby and cool projects using it. I guess that's the trade-off. But, well, it took so much effort to get heroku installed that I haven't used ruby since.
The big one is ActiveSupport. There are many extensions to common Ruby objects like String, Enumerable, Hash, etc. For example. In Rails, you'll use something like this quite frequently:
some_string_var.parameterize
EDIT: My last paragraph isn't clear enough that you can use ActiveSupport outside of Rails by simply adding the gem to your Gemfile and requiring it in the relevant location. The downside is that you create a dependency. If you are writing ad hoc scripts, this can be an annoyance, but if you package all your scripts as a Gem using something like Thor, dependencies won't be a problem.
Not knocking Rails, it's just that you'll get a really narrow and somewhat skewed perception of Ruby if you learn it through Rails (you'll have no way of easily separating the Rails magic from plain Ruby as you learn things).
From the description it seems like he doesn't quite get the distinction himself, and one of the later examples is broken:
"Array.new.methods - Object.methods" should read "Array.new.methods - Object.new.methods". Otherwise he's in fact subtracting the methods available on an error instance from the methods available on an instance of Class, not the methods available on a generic object..
You are wrong, classes are objects :)
1.9.3p194 :084 > Object.new.methods - Object.methods
=> [] irb(0main):001:0> Object.methods - Object.new.methods
=> [:allocate, :new, ...]
Consider for example, a "Person" class with a single instance method "name". In this case, "Person.new.methods - Object.methods" will not include "name", because this happens to be a method that applies both to Person instances and the object Object. The correct comparison is what vidarh said, "Array.new.methods - Object.new.methods".
The author's main point, however, was that you can write code like "Array.new.methods" and "Object.methods" at all, and that you can write code to subtract them. And this example shows that nicely.
On the article, I strongly disagree that vim requires plugins to be viable for Ruby development. The Janus plugin should especially be carefully considered as it wraps up a lot of magic that could prevent the new vim user from effectively learning vim itself.
`while true` usually does it for me.
[1,2,3].index(1)
# => 0
[1,2,3].index(4)
# => nilI have spent the past three weeks getting my head into Ruby (on the hopeful way to understanding Rails). With so many different languages and stacks, it makes the early stages extremely daunting for a beginner.
I have found comfort in the following resources:
1) The only website I found that actually visualized how everything sits together: http://techiferous.com/2010/07/roadmap-for-learning-rails/
2) I persevered with a Ruby programming book: Beginning Ruby: From Novice to Professional (by Peter Cooper)
3) Spent a few days on a zero install Ruby tutorial: http://tryruby.org
I plan to write some blog posts on the journey however may wait until I get passed the basics before sharing too much.
1. Who is actually new to Ruby?
(After Ruby or rather the popular RoR is there almost for a decade everyone should have made some experiences with Ruby, so I am wondering if there are many new Rubiest)
2. What new language/stack did you start to learn recently?
(for me: Node.js)
Opinions will differ, of course. Both languages are tops.
I suspect your comment is being buried for the pretentiousness of that question. Plenty of people are still new to Ruby, because you absolutely do not need Ruby to have a successful development career. Not to mention the population of individuals who are completely new to programming.
In my experience it is still vastly harder to hire someone with any degree of Ruby exposure vs. PHP developers, for example.
Ruby is still a niche language.