[e12e]

> Languages with a single way to do things benefit the most: Ruby

I love ruby - but surely it's closer to Perl and "There's more than one way to do it" - than python which generally strives for "There should be one-- and preferably only one --obvious way to do it."?

https://legacy.python.org/dev/peps/pep-0020/

[dasil003]

In practice, Ruby is much more opinionated than Perl, mostly because of Rails being the catalyst to drive mass adoption of Ruby. So you basically have Rails, and then the RubyGems/Bundler package management was pretty linear. There's no equivalent of python2->python3 schism and the package management churn, and more stylistic continuity since ruby adoption is lower and more concentrated in the 2005-2015 time frame compared to python which had greater diversity of adoption and use cases both before and after the Web 2.0 era. I do feel pythons explicit imports and cultural aversion to meta programming win it some points. Overall though it kind of feels like a wash and I still choose the language based on the some criteria I would have used before agentic coding--claude does fine with either.

[MattRogish]

Yes! It reminds me of the tabs vs spaces argument. Yeah, you have your preference, but as long as everyone on your team uses the same convention it doesn’t matter

The Rails apps I’ve programmed with LLMs seem to work a LOT better than arbitrary python or ruby or JavaScript apps. I chalk that up to “there are a gazillion examples of omiauth in Rails that the LLM can’t really stray off the path. It just works.”

That means I let the agent do things the way it wants to, not because I have a preference. So we’re using turbo and Hotwire and whatever it is it’s doing. And I’m using React for some other problems. Not because I know React, but because the LLM does.

In golf it is said to “let the club do the work”. Over control leads to disaster. Same with LLMs. Not saying let it do whatever but if there are widely baked in conventions you’ll be far better off letting those do the work.

[jimmaswell]

> There's no equivalent of python2->python3 schism and the package management churn

I tried to run a Ruby script recently and got an error about Fixnum. Apparently they made some breaking change to how integer types are referenced in version 3. I had to modify the script to get it to work on a modern parser. How is this not equivalent to the Python 2-3 jump? I don't know the first thing about Ruby but this already told me that it's a language with breaking changes between versions.

(It was the ruby scripts here if anyone is curious: https://github.com/haberman/vtparse/ )

[coldtea]

>How is this not equivalent to the Python 2-3 jump?

The same way triping on a small pothole is not the same as falling into a giant sinkhole.

The claim was not that Ruby had no incompatible changes whatsoever.

[jryio]

Correct, even though Ruby the language exists and predates Rails. What -- 80%+ of all Ruby code is Rails? Effectively the largest consumer and producer of the language which I think is a net benefit to your point.

Correct in that Ruby never had a schism and is still massively productive and wideley deployed (e.g. Shopify + Stripe alone represent billions/trillions of dollars through Ruby hotpaths).

Python's general lack of success in this domain is telling and embodies whats I was trying to communicate in the article -- languages with low entropy in syntax, features, ecosystem, and toolchain compound slowly.

[_jackdk_]

My experience has been the exact opposite. Python seems to churn its packaging and tooling at an astonishing rate, whereas Rails forced a centralisation of its ecosystem.

[onlyrealcuzzo]

I can assure you that it's not worth your time to have LLMs write non-trivial code in Ruby.

I doubt Python is significantly better.

The problem isn't that there's more than one way to write working code.

It's that there's infinite ways to write working code, and nearly all of them are bad, and any dynamically typed language allows for a lot of type slop that you don't want.

There's a lot more opportunity for LLMs to write terrible working code in Ruby or Python than there is in Rust, for example.