Ruby

Ruby is the language underneath three of the things on this page (Rails, Jekyll and Redmine), and that is no coincidence. People choose it when they want the code to stay readable.

Why we still choose it

Matz’s stated design goal was programmer happiness. That sounds like marketing until you have maintained something for five years. Ruby is written for the reader, meaning 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 cares about naming produce code you can read without having to decode it.

Ten years ago the performance objection was fair. It mostly is not now: YJIT has closed much of the gap, and in 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

We use Rails when a system needs per-user state, Jekyll when a site does not, and Redmine when a company wants its project history on its own disk. Because all three share a language, one set of skills covers the estate and one Ruby version policy covers the fleet.

Where it falls short

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