[cycomachead]

More productive is really hard to say... But I personally prefer Ruby to Python. For smallish scripts, I really like Ruby's backticks for easily executing shell commands. And I find the metaprogramming support in Ruby great for some tasks. I'm not sure if that's what you're getting at.

But especially with "modern" Python features like f-strings and the walrus operator there's not tons of differences that really stand out as "productivity".

One thing to just remember: Ruby is not just the Ruby on Rails community. Rails is a dominate space, but it's not the only thing out there. At the same time, when it comes to scientific computing, ML, etc. the Python ecosystem is incredibly robust. There's plenty of awesome Ruby tools for these things too, but it is not the same.

Ruby and Python are the two languages I primarily teach courses in, and used professionally. Ruby is my cup of tea personally, but they're both modern dynamic interpreted languages.

[ptx]

> For smallish scripts, I really like Ruby's backticks for easily executing shell commands.

Executing external commands is pretty convenient in Python these days, now that we have subprocess.run [1], and passing the command as a list rather than through the shell seems a lot safer.

Doesn't backticks open up the classic command injection issues (i.e. the same kind problem as SQL injection with non-parameterized queries) unless you're extremely careful to manually apply proper quoting in every single case?

[1] https://docs.python.org/3/library/subprocess.html#subprocess...

[noirbot]

It would, but most of the time when I'm using backticks, it's because I'm writing myself/my team a little helper script that will never get "injected" with anything. Backticks (and the other more featured ways of doing shell commands in ruby) make it really easy to write what amounts to a Bash script, but with a little more features and readability, or pull in some relevant libraries for some more complex task that would be annoying to do in pure Bash.

[ptx]

Your use case might be different from mine, but I find that usually there is some parameter needed for the command, usually a filename or sometimes the output from another command. Even if you're not accepting hostile data over the network, you probably want it to work correctly for any valid filename.

With a bash script, or shell commands as strings in general, I can usually with some work be reasonably sure that I'm handling filenames with spaces correctly, so that it doesn't explode when it encounters something unusual... mostly, probably, in most places ... I hope. But what about filenames with newlines? Probably not as correctly. Etc.

With a parameterized API, this all just works and is correct for all cases, so you don't have to think about arcane quoting rules.

[noirbot]

To be fair, there are some of the more complex ruby libraries that do provide those more protected/parameterized options. In general, even when I wrote a script that took input, I found it sufficient to just assume that if another dev tried to use it for something where it broke, they could work out how to fix it, or rename the file/folder on their system to make it work.