[azangru]

Could you point out specific parts of python that are easier for someone with C/C++ background as opposed to Ruby? I remember starting with Ruby (after rudimentary CS50-level C), and finding it quite reasonable and logical, and nicer than python. I still think it's nicer than python, although I've long since stopped using it.

[shagie]

I believe the issue isn't so much "vanilla python" vs "vanilla ruby" for a developer coming from a C background but rather that ruby's programming style leads to a significant bit of meta programming which (aside from being a bit of a challenge to get one's head around) leads various shops and frameworks having built their own DSL for writing ruby.

Open classes give me the security heebie jeebies.

    irb(main):001:0> "foo".bar
    (irb):1:in `<main>': undefined method `bar' for "foo":String (NoMethodError)
            from /usr/local/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>'
            from /usr/local/bin/irb:25:in `load'
            from /usr/local/bin/irb:25:in `<main>'
    irb(main):002:1* class String
    irb(main):003:2*   def bar
    irb(main):004:2*     "foobar!"
    irb(main):005:1*   end
    irb(main):006:0> end
    => :bar
    irb(main):007:0> "foo".bar
    => "foobar!"
    irb(main):008:0> 

On one hand, that's really neat. On the other hand, the ability to add or modify a method in a system class is not something that I'd want near production code. I'm sure that other orgs have sufficient checks and style guide to prevent something from creeping in... but that sort of flexibility in the language is something that I'd prefer to stay away from if I want to be able to reason about ruby code.

See also Ruby Conf 2011 Keeping Ruby Reasonable by Joshua Ballanco https://youtu.be/vbX5BVCKiNs which gets into first class environments and closures.