Built a RAG tool in Ruby to surface historical context from Jira, Confluence, and GitHub before starting work on client tickets. No prior experience with embeddings or vector databases. Ended up adding an MCP server so it works directly inside Claude Code.
I wrote this after noticing how much framework discussion focuses on greenfield work. In practice, most teams I see are inside 10 or 12 year old systems, evolving them under real constraints.
The piece is about that “second act” of software. After launch. After early growth. When reliability and discipline matter more than novelty.
A deep dive with Rainforest QA’s Jay Tennier on what it takes to keep a long-lived Rails monolith alive with a small team. We cover pulling microservices back in, BigQuery over Postgres pain, wet tests, dry-monads, and why code deletion is a feature.
This take is almost as condescending as saying that Ruby isn't a serious language.
Ruby arose and became popular because it caters to a niche that was underserved by the competitors of the time (and while I'm no historian, I think Rails had a big role to play in Ruby's popularity).
Ruby is very ergonomic, and so is Rails. Frankly, almost 10 years after moving on from it, ActiveRecord is the yardstick by which I measure the ergonomics of all other ORMs in other languages, but what ergonomic means will vary from domain to domain.
With languages like Ruby and Python, it's very easy to get from nothing to an app that will work generally well enough almost straight away. A lightweight syntax, a lot of implicit functionality, and a flexible type system are all great for that, but in my current niche, I couldn't use it (I currently work with Rust, and the explicit control is a huge selling point, despite the much heavier syntax and more complicated semantics). That doesn't mean Rust was built without the human experience of using it in mind, though, and arguably the opposite's true.
At the time, Java. J2EE (entity beans and session beans), Java Server Pages, Apache Struts. I think it's hard for people who didn't live through it to appreciate just how painful it was to work in that stack circa 1999-2003, like it just doesn't seem plausible that the whole industry would go along with a stack with that much boilerplate for that little added value.
Back then, Ruby and Rails opened a lot of people's minds to the idea that we were allowed to make "delightful" a consideration in API design, not just S.O.L.I.D. or whatever. These days, there are way more mainstream languages, frameworks, and communities that take humane APIs seriously.
Putting aside the fact that this is about ruby vs other languages, not rails vs other frameworks, I cannot help but feel like ruby optimizes for fitting code onto slide decks rather than other human concerns (like, unambiguous communication of semantics at a glance).
I certainly have written a great deal of ruby and have no strong opinions about the language aside from "I will shoot the next person who uses method_missing", but I find the people who do have strong attraction to the language endlessly fascinating. By far, the most human aspect of the language is the community built around it.
reply