Ruby

Ruby is the language underneath three of the things on this page — Rails, Jekyll and Redmine — and that is not a coincidence. It is the language people reach for when the priority is that the code stays readable.

Why we still choose it

Matz’s stated design goal was programmer happiness, which sounds like marketing until you maintain something for five years. Ruby optimises for the reader: the person opening a file they did not write, at the wrong hour, trying to work out what it does. Blocks, expressive standard-library methods and a culture that values naming make a codebase that can be read rather than decoded.

The performance objection was real a decade ago and is mostly historical now. YJIT has closed a great deal of the gap, and for the workloads we build — request handling, background jobs, report generation, static site builds — the bottleneck is almost always the database or the network.

Where it shows up in our work

Rails applications when a system needs per-user state. Jekyll when a site does not. Redmine when a company needs its project history on its own disk. In all three cases the fact that they share a language means one set of skills covers the estate, and one Ruby version policy covers the fleet.

The honest limit

Ruby is not the answer for a CPU-bound numerical workload, a systems daemon, or anything where a fifty-megabyte runtime is unacceptable. We are happy to write those in something else. The claim is narrower and more defensible: for the business logic of an ordinary organisation, a readable language with a settled ecosystem beats a fast one nobody enjoys maintaining.