To add some quick answers in my experience:

1. It's a general attitude toward building interfaces; the reader of the code is put first. Yeah underneath things may be messy, but using those things should be nice. The onus is placed on the implementor, rather than the user. Ruby libraries will go to fairly extreme lengths to make things nice to use.

2. Matz has always said that he meant the path of least surprise to him, not to every programmer. I personally find this point the weakest.

3. Yes, stuff like rubocop can help teach you this, but you really pick it up from reading and writing others' code.

4. Ruby has had a test-focused bent for a long time; and so it has a lot of tools for testing. Back when I taught Ruby professionally, I even had an organization with a Perl webapp want me to teach their testers Ruby, to write test suites for the app in Ruby rather than Perl. Perl also has great testing, so I'm not sure I agreed with them in this case, but it is something many people feel.

5. I've seen many unmaintainable Ruby apps as well; I think this is something that should be aspired to overall, not necessarily something that's true today. Or rather, there's a period of development where people get enthused with a language, write tons of unmantainable code, step back, figure out why, and then the next iteration is better. Justin points out that node, being earlier in its life, might be in step 2, and that Ruby, being more mature, is on step 4 or 5 here.

> 1. It's a general attitude toward building interfaces; the reader of the code is put first. Yeah underneath things may be messy, but using those things should be nice. The onus is placed on the implementor, rather than the user. Ruby libraries will go to fairly extreme lengths to make things nice to use.

I struggle with this a little as newish ruby coder (but not new to coding). The efforts to make a 'nice' interface can interfere with keeping underlying implementations elegant/simple.

Too much focus on the happiness of a dev cranking out new code at the expense of the happiness of developers coming along afterwards trying to understand it.

Ruby is fun to create stuff with, but I kinda prefer the Python culture that tries to drum into devs the importance of readability and explicitness for other developers. As a dev you do far more poring over others code than creating brand new stuff.

Explicitness. << This is key. Ruby/Rails just feels really implicit and magical for someone who spent the first 15 years of his career in C++, C#, and JavaScript. (I've only been doing Rails professionally for a year, though, so maybe my opinion will change with more experience.)

That's mostly an effect of Rails. "Convention over configuration" was one of the early mantras, and usually it serves well for such a large API...but sometimes it's just magic.

Ruby itself is a fairly explicit and consistent language. Some of the syntax might seem surprising at first if you haven't bought into the "everything is an object (really)" perspective.

Chef is pretty magical as well. I think it's easy to get carried away with syntax-sugary DSLs at the expense of of straightforwardness in Ruby if you aren't disciplined about simplicity.

I think the programmer happiness is more about the language itself than tools or whatever. For example, I've been doing exercism.io in Ruby and a couple of other languages. I find that because of the the syntax and extensive standard library Ruby offers, I can almost always write the most concise and readable solutions in Ruby.

re.2, to find where a function was defined, use source_location on the Method instance. e.g. I have this in a dev-specific initializer:

    class Method
      def subl
        system("subl", source_location.join(":"))
      end
    end

Now if "response.context" is throwing an exception, I can find its definition with

    response.method(:context).subl

Et voila, the source file is opened in Sublime Text and positioned at 'def context'. This even works for the nutty stuff, like methods defined dynamically in an eigenclass.

Also, pry & better_errors are your friends.

I heard of Rails before Ruby, so did a lot of people. That's your answer right there.

Ruby on Rails when it came out was: - A tool with a culture that was optimized for programmer happiness and productivity. - Promoting obviousness via the path of least surprise. - Consistency through well-considered conventions. - Carefully-designed value-based test suites. - Building long-term maintainable apps.

Most of the good thing you hear about ruby are actually coming from Rails.