Similar feelings here. Ruby's philosophy of providing a ton of different ways to do the same thing can lead to some pretty sweet-looking code, almost like poetry... but I'd rather have Python's stylistic consistency and better-integrated type hints. Now that Python has Poetry and uv, Ruby's main remaining advantage has evaporated and it's hard for me to justify using the language.
Another thing I don't like about Ruby is how much the community has embraced the Clean Code brand of readability snake oil. It's easy to come by the opinion that any function over 5 lines is a code smell and over 10 lines it's outright bad. I've even heard the view that if-else statements are a code smell and I should always try to replace them with different classes that have the same interface. To be fair, that only happened twice, but that's two more times than I've heard it from users of any other language. I think that the Python community usually strikes a better balance between avoiding excessive function/class length and avoiding excessive indirection.
> Another thing I don't like about Ruby is how much the community has embraced the Clean Code brand of readability snake oil.
This also puts me off every time, and I've dealt with people who embrace this a lot as a Ruby programmer. Fortunately, you can ignore them and still enjoy writing Ruby code the way you want.
I inherited a project where this was taken to the extreme. We have a class that's used to calculate final pricing taking into account discounts, coupons, shipping fees (or free shipping). Each one of those values was implemented as methods but then we have a call like: method_a - method_b + method_c, but it turns out, method_a may be adding shipping_cost for it to then be subtracted out in method_b. We ended up refactoring this and removing all the needless methods and just have a simple inline calculation. Definitely not "clean".
PHP has its significant flaws, but superficial syntactic differences aren't among them. In my experience, it takes two weeks to get used to pretty much any syntax.
Is that different from what is happening already? A lot of people won't adopt a language/technology unless it has a huge repository of answers on StackOverflow, mature tooling, and a decent hiring pool.
I'm not saying you're definitely wrong, but if you think that LLMs are going to bring qualitative change rather than just another thing to consider, then I'm interested in why.
I don't know if I'd recommend it, but checking, Sawyer's _Group Genius: The Creative Power of Collaboration_ book hits most of the points I'd cite about brainstorming in its chapter, so you could always start there.
> My theory: what matters isn't "best practices", it's have a coherent conceptual design and code that reflects that design.
I think so too; that said, the language could definitely be better. It suffers from a lot of primitive obsession. Instead of structs, you often find either vectors or lists with predefined element positions; instead of map, ordered map, and multimap types, it's just various kinds of lists everywhere. They're not even used consistently: for the same thing, one package may use an alist and another a plist.
Yeah, I could also see some improvements like that. But, compared to other codebases I've worked with that had the same problem (cough nixpkgs cough), it's amazing how much better the Emacs programming experience has been.
Programming with string templates, in a highly complex and footgun-rich markup language, is one of the things I find most offputting about the DevOps ecosystem.
Several years ago when I was writing a deployment system for a cloud distributed database, I tried to automate everything with Ansible playbooks and the Ansible "API" (LOL). I pretty quickly gave up on implementing anything but the most trivial logic in templated YAML and switched to Python (wrapping maximally-dumb Ansible playbooks) for everything nontrivial.
Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part, instead delegating to its terraform connector, which drags in all the nonsense that entails. That makes it not only less useful but (IMHO) a horrible name for a project that only does "remote execution" and not infrastructure. The fact that it's even missing @aws @azure @gcp connectors further solidifies "who is the audience for this thing?"
Not everyone runs cloud servers. pyinfra seems to fit my needs like a glove, so I guess I am the intended audience.
I never liked the provisioning overlap Ansible has with Terraform, so it makes sense to me: provisioning servers with tf, configure them with another tool, whether it’s ansible or pyinfra. Well, at least in theory
There’s a lot more to infra than the cloud, pyinfra is designed to work in any of these environments not just the over-abstracted, over-hyped cloud. There’s plenty of good tools for setting up the infra, any pyinfra can easily be integrated.
> Just about every time someone complains about ansible, there's a comment to plug this project but pyinfra seems to opt-out of the cloud provisioning part
Which Ansible is absolutely atrocious at, so that makes sense. Use the best tool for the job (so Terraform, maybe Pulumi/tfcdk if you hate your future self/future teammates for infra.
This is why I generally use Terraform for Kubernetes. It's not perfect, but it's miles better than the various different YAML-templating solutions (Kustomize, Helm) popular in the Kubernetes ecosystem.
To be fair one of the most common ways of managing Kubernetes clusters and what is deployed on them is to use ArgoCD, which gives you the same issue of dual stateful control planes.
Even more fun is if you then run your Kubernetes cluster on top of a VM orchestrator such as vSphere, that way you have multiple layers of stateful control planes and compute orchestrators fighting each other.
Yes, plenty of experience in the first two, but the last two are better contenders. At any rate I work primarily with TS when I do front-end code, it's very rare for me to write raw JS, so a lot of footguns automatically go away.
Another thing I don't like about Ruby is how much the community has embraced the Clean Code brand of readability snake oil. It's easy to come by the opinion that any function over 5 lines is a code smell and over 10 lines it's outright bad. I've even heard the view that if-else statements are a code smell and I should always try to replace them with different classes that have the same interface. To be fair, that only happened twice, but that's two more times than I've heard it from users of any other language. I think that the Python community usually strikes a better balance between avoiding excessive function/class length and avoiding excessive indirection.