The multi-language capstone -- three microservices, one in each language, talking to each other -- is ambitious. If you pull it off, it's an incredible portfolio piece. A Rails engineer who can build and ship production services in Go, Rust, AND Zig? That's a unicorn hire. But let me be honest about reality.
By this point you've been studying systems languages for 12-18 months on top of a full-time job and whatever else life throws at you. You might be burned out. The novelty has worn off. The dopamine of "I learned a new concept" has been replaced by the grind of "I need to ship something complete." And that's okay. Burnout doesn't mean failure. It means you're human.
Even building ONE capstone in your strongest language is valuable. That will probably be Go, since it's first in the curriculum and most natural for Rails developers. A well-built, well-documented Go project on your GitHub is worth more than three half-finished projects in three languages. Shipping beats ambition every time.
The capstone should solve a real problem you care about. Not a toy exercise. Not a tutorial project. Something you'd actually use. Ideas: a performance monitoring sidecar for Rails apps (Go is perfect for this). A CLI tool you genuinely need in your workflow. A library that wraps a C dependency you've been fighting with in Ruby. If you build something you'll actually maintain, the project stays alive on your GitHub. Dead repos with one commit from 18 months ago impress nobody.
Ship it publicly. Write a README that explains why you built it, what you learned, and what tradeoffs you made. The code matters less than the judgment it demonstrates. An interviewer scanning your GitHub wants to see that you can think about systems, not that you can write perfect Rust. A thoughtful README showing you understand when Go's GC tradeoff is acceptable versus when Rust's zero-cost abstractions matter -- that's what separates a senior engineer learning new tools from a junior engineer collecting languages.
The hardest part of capstone projects is finishing them. The learning part is fun. The building part is exciting. The shipping part -- handling edge cases, writing tests, cleaning up the API, writing documentation -- is discipline. Most capstone projects die in the last 20%. Don't let yours be one of them. Set a deadline. Cut scope ruthlessly. Ship something small and complete over something large and abandoned.
You're a Rails developer. You know how to ship. Apply that muscle here.