Mostly agree with José's tweet linked in the article: the effort required to make anything better is lowered substantially. For example, the primitives for Ruby concurrency to be good have been there for 3-4 years. Many long-established ecosystem libraries and conventions didn't adopt these newer tools, and I don't blame them for that. Many might have required breaking changes. Breaking changes are a tough sell for decade-old, stable libraries. Then for application teams, prior to agentic engineering, it would be a big lift to migrate large projects to a new set of libraries. But that's not the case anymore!
Ruby is never going to be a BEAM language or Rust, but I'm pretty excited for the near-term performance improvements in Ruby; not only the base language (e.g. Spinel), but in the broader ecosystem. When you avoid a handful of footguns, you maintain some basic architectural consistency/organization (and get your agents to do the same), Ruby continues to have a good balance between expressiveness, and the ease of reasoning about the code, relative to the amount of annotations and boilerplate you need to throw in to get there.
For someone who is persuaded they should never read the code anyway, then that's not a benefit that they desire, vaya con dios! There's not much conversation to have when working from such different premises.
Ruby is never going to be a BEAM language or Rust, but I'm pretty excited for the near-term performance improvements in Ruby; not only the base language (e.g. Spinel), but in the broader ecosystem. When you avoid a handful of footguns, you maintain some basic architectural consistency/organization (and get your agents to do the same), Ruby continues to have a good balance between expressiveness, and the ease of reasoning about the code, relative to the amount of annotations and boilerplate you need to throw in to get there.
For someone who is persuaded they should never read the code anyway, then that's not a benefit that they desire, vaya con dios! There's not much conversation to have when working from such different premises.