ruby/ruby: a mirror clone, an autotools build, and two Rust JITs that skip Cargo

git clone gives you a mirror, and git.ruby-lang.org is the one committers use

Two commands are given, and both point at GitHub:

git clone https://github.com/ruby/ruby.git
git ls-remote https://github.com/ruby/ruby.git

The second one exists to list the branches under development, which is the hint that master is not the only line of work in this repository. Then the page names a second location, https://git.ruby-lang.org/ruby.git, and labels it the actual master of Ruby source for anyone who is a committer. So the clone step a newcomer runs is explicitly a mirror, not the authoritative history. The practical consequence is about provenance rather than speed: if you are auditing commits, writing a patch, or bisecting a regression, the GitHub copy may not be the tree the project considers canonical, and the page gives you no way to check the two against each other.

There is no package manager entry point, only a downloads page and an rvm mention

Nothing in the page tells you to run an install command, and that is the point: this is the source repository, not a distribution. Getting a usable Ruby means leaving it. The page points to ruby-lang.org/en/downloads/ for a complete list of ways to install, naming third-party tools such as rvm, and to a separate releases page for whole versioned downloads, adding that you can also download the snapshot of the repository. What that costs a reader is one extra decision before you even start: the repository is the last step, not the first. If you wanted a language to write an application with, every path here is a detour past a page that hands you a binary, whereas if you want to read the interpreter, going straight to the clone is the correct move and this page is enough.

autogen.sh and configure.ac put autotools, not cargo, on the build path

The top level of the tree is a C project that happens to share a directory with some Rust. You can see it in the file names: aclocal.m4, configure.ac, common.mk, depend, autogen.sh, and C sources paired with Ruby files for some modules, such as array.c and array.rb, ast.c and ast.rb, and debug.c with debug_counter.c beside it. The build instructions are not in this repository either; the page links out to the Building Ruby guide under docs.ruby-lang.org and says the contributing guide includes setup and build instructions. So a first build is a documentation task before it is a shell task. What you cannot get from the repository root alone is the flag list, the dependency list, or the platform notes, and the portability claim in the feature list points at a separate maintainers page for which platforms are actually built.

Cargo.toml is in the tree, and the file itself says release builds avoid Cargo

Cargo.lock and Cargo.toml sit at the top level, which invites the assumption that cargo build produces Ruby. The file says otherwise in its own comments:

[workspace]
members = ["zjit", "yjit", "jit"]

[package]
name = "ruby"
version = "0.0.0"
edition = "2024"
rust-version = "1.85.0"
publish = false

The version is a placeholder zero, publish is false with a note not to publish to crates.io, and a comment explains that release builds avoid Cargo entirely because offline builds can fail even when none of the optional dependencies are built. It also says not to add required dependencies, as a policy that gives the maintainers tight control over what ships, with optional dependencies used only during development. The consequence for a reader is that cargo is a development convenience here, not the release toolchain, and that the crate named ruby is an internal static library rather than something you depend on.

yjit, zjit and jit share one staticlib because Rust cannot link them separately

The three workspace members explain why the Cargo file is shaped the way it is. A comment at the top says this is both the root workspace and the root package for all the Rust code statically linked into Ruby, and that Rust tooling limitations mean all Rust code has to share a single archive library at the integration point with the non Rust code. The lib section confirms it, with crate-type set to a staticlib and the path pointing at ruby.rs. Features are named after the crates, disasm, runtime_checks, yjit and zjit, and the optional dependencies point at the yjit and zjit paths. The consequence for a reader is that there is no per crate Ruby extension to install: the JIT is compiled into the interpreter binary, which is why switching it on and off is a build configure option rather than a loadable module.

KNOWNBUGS.rb and .rspec_parallel are where known failures are recorded, not the issue tracker

Three directories in the tree carry the test story, and they are different in kind. basictest/ is the language smoke suite, bootstraptest/ checks a build that has just compiled itself, and benchmark/ exists for timing. Alongside them sit KNOWNBUGS.rb, a file of failures that are already documented, and .rspec_parallel at the top level, which configures how the rspec suites are distributed. Bugs go to bugs.ruby-lang.org, with the reporting guide linked.

Two feature list entries carry their own caveat about architectures and platforms

The feature list is short and one entry is narrower than the headline suggests. Dynamic loading of object files is qualified as working on some architectures, not all of them. Portability is described as working on many Unix-like and POSIX compatible platforms as well as Windows and macOS, and the same entry links out to a platform maintainers page rather than claiming a fixed list. The rest of the list, simple syntax, normal and advanced object orientation with mix-ins and singleton methods, operator overloading, exception handling, iterators and closures, and garbage collection, carries no such qualifier. What the caveats cost you is that the two things most likely to differ between machines are exactly the two with an asterisk, so a feature that works on your workstation can fail on a platform nobody has wired into the maintainers list.

Subscribing to ruby-talk takes one word in the subject line, and bugs go elsewhere

Discussion and defect reports are split across two channels, and the instructions are unusually literal. To join the mailing list you send the single word join in the subject line, not in the body, to the request address, and the page stresses subject, not body. Questions about the language then go to Ruby-Talk or to Stack Overflow, while bugs go to bugs.ruby-lang.org with the reporting guide linked. The consequence is a routing rule: a question sent to the bug tracker and a patch sent to the list both land badly, and the subject line detail is the kind of thing that costs a newcomer a day of silence if they do not read it.

Editorial conclusion

ruby/ruby is the right repository for reading how the language is implemented, for hacking on the interpreter, and for anyone who needs the JIT crates, and it is the wrong place to look for the Ruby web framework or for a package you install with a gem command. Before you build, read the building guide linked from the page, expect to install a compiler toolchain and Rust 1.85.0 or newer for the JIT crates, and remember that the branch you clone from GitHub is a mirror rather than the one committers use.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. ruby/ruby on GitHub