Python is easier to use if you come from a C/C++ style coding background.

adriand · on Oct 25, 2022

I also think it is easier to use, period. I've used Ruby professionally since the Rails 1 days, and still program in it most days. A couple of years ago, while working at an AI company, I helped out on an ML project due to a time crunch, and I needed to use Python to contribute. I wasn't asked to do anything ML-specific, but rather help by building out infrastructure and data processing pipelines, i.e. the stuff that used the ML models.

I'd never used Python before but within a couple of hours I was writing code and in less than a week I'd engineered a pretty slick, very robust pipeline. I was quite honestly fairly astonished at how quickly I became productive in the language.

I could be wrong about this (my experience with Python started and stopped in that one week) but the impression I got was that Python is smaller, more constrained (i.e. fewer ways to do the same thing), and syntactically less complex.

choppsv1 · on Oct 25, 2022

Python is easier to use if you come from almost any background, programming or not. I believe this is primarily b/c there isn't a lot of "special syntax" in Python, it's all very explicit and common. The same is not true with Ruby.

azangru · on Oct 25, 2022

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 · on Oct 25, 2022

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.