Ruby is a dynamically typed, object-oriented language released in 1995, and for most of its working life it has been used in the same few places: web applications, command-line tools, build and deployment scripts, and the test suites around all three. This section covers the parts of it that come up in the same conversations conference talks come up in, which is a narrower subject than the language as a whole.
The shape of the language
Everything is an object, including integers and nil. Blocks are passed to methods as an ordinary part of the calling convention rather than as a special case, which is why so much Ruby reads as a statement with an indented clause attached. Classes stay open after they are defined. And there is almost no ceremony: a file containing one line is a valid program.
The consequence for anybody reading Ruby for the first time: there is very little scaffolding to orient by. No type declarations at the top, no compilation step to complain, and frequently no explicit indication of where a method came from. That is the same property that makes it quick to write.
Ruby and Rails are not the same subject
Most people meet Ruby through Rails, and a large share of what looks like language behaviour is framework behaviour. Telling the two apart is the single most useful early skill, and it is the subject of learning Ruby from the newcomer’s side and Rails from the framework’s.
The practical version of the distinction: a problem is a language problem if it would still happen in a file run on its own, a gem problem if it goes away when a dependency is removed, and a framework problem if it depends on where the file sits in a directory tree.
What this section covers
- The release timeline, which versions are still supported and what actually changed in each one.
- Static analysis tools, compared: what each one checks, how much configuration it needs and how it behaves in a build.
- Gems and Bundler, which is where most of the early trouble with an environment actually comes from.
- Rails, and which of its conventions are worth knowing before the rest of it.
- Testing, where a great deal of the language’s culture lives.
- A learning path, in the order that causes the least trouble.
Why a conference reference carries a language section
Because the questions arrive together. The practice sections on this site do not depend on a language at all: a review rubric, a sponsorship prospectus and a beginner track work identically at a Python, JavaScript or Go event. But the person asking how to propose a talk is frequently also the person deciding which version to run in production, and the two questions are asked in the same week.
The practice does not need a language. The people asking about it do.
The material here is kept to what is stable. Version support and the behaviour of a linter change slowly and can be written down; the merits of a particular gem this year cannot, and are left out.
Where the name on this domain comes from
Ruby Hoedown was a free regional Ruby conference that ran in the American South between 2007 and 2012, and the domain takes its name from it. The two editions with the fullest public record are documented at 2007 and 2008, and the wider circuit those events belonged to is covered in the regional conference index. If the word itself is what brought a reader here, hoedown has a page of its own.
For the conference practice this site is mostly about, conference practice is the starting point, with the call for speakers for anybody thinking about proposing a talk.
Questions
What is Ruby used for?
Mostly web applications, and mostly through Rails. After that, command-line tools and automation, then libraries and gems, then a long tail of scripting and data work. The shape of that distribution is why so much advice about the language is really advice about one framework.
How can a language problem be told from a framework problem?
A language problem still happens in a single file run on its own. A gem problem goes away when a dependency is removed. A framework problem depends on where the file sits in a directory tree. Asking that question first saves most of the time otherwise lost.
Is Ruby still worth learning?
It remains in wide production use, particularly in web applications and in tooling, and the ecosystem around testing and deployment is mature. Whether it is the right first language is a different question from whether it is worth knowing.
Does a conference reference need a language section at all?
The practice sections do not: a review rubric or a sponsorship prospectus works the same at any event. This section exists because the person asking how to propose a talk is often the same person choosing a version to run, in the same week.
Why is this domain called Ruby Hoedown?
After a free regional Ruby conference that ran in the American South between 2007 and 2012. The two editions with the fullest public record are documented here, and the word itself has a page explaining where it comes from.